QoS-Markierung an der Netzgrenze: Trust Boundary im Telco-Netz

QoS-Markierung an der Netzgrenze ist im Telco-Netz der entscheidende Punkt, an dem sich entscheidet, ob QoS überhaupt funktioniert – oder ob Premium-Klassen zur wertlosen „Kosmetik“ werden. Genau hier kommt die Trust Boundary ins Spiel: Sie definiert, an welchen Übergaben (UNI, NNI, CPE, Provider Edge) DSCP-, CoS- oder MPLS-TC-Markierungen akzeptiert werden dürfen und wo nicht. Ohne eine klare Trust Boundary passieren in der Praxis zwei Dinge: Entweder werden Markierungen blind vertraut, sodass Kunden und Endgeräte „alles als Premium“ markieren können (Premium-Inflation, Starvation, instabile Netze). Oder Markierungen werden überall neutralisiert, sodass selbst korrekt markierter Voice- und Video-Traffic im Best Effort landet und unter Last leidet. Professionelles QoS im Provider-Netz ist deshalb immer auch ein Sicherheits- und Betriebsmodell: Markieren, Validieren, Normalisieren und Profilieren an kontrollierten Grenzen – und danach konsistente Behandlung im Metro- und Core-Netz. Dieser Artikel erklärt die Trust Boundary im Telco-Netz leicht verständlich, zeigt typische Grenzpunkte, bewährte Trust-Modelle (Untrusted, Trusted, Conditional Trust), praktische Designregeln für DSCP/CoS/MPLS-TC sowie häufige Fehler, die zu schlechter Sprachqualität, Video-Rucklern oder schwer nachvollziehbaren SLA-Diskussionen führen.

Warum Trust Boundary die Basis jedes QoS-Designs ist

QoS lebt von Differenzierung: Nicht jeder Traffic ist gleich. Voice braucht niedrige Latenz, Video stabile Ressourcen, Best Effort Fairness. Diese Differenzierung beginnt mit Markierungen wie DSCP (IP), CoS/802.1p (Ethernet) oder MPLS-TC/EXP (MPLS/SR). Das Problem: Markierungen sind leicht zu setzen. Ohne Kontrolle können sie missbraucht werden – absichtlich oder unabsichtlich.

  • Missbrauch: Ein Kunde markiert Downloads als EF/Voice und verdrängt andere Klassen.
  • Fehlmarkierung: Applikationen oder Endgeräte markieren „zu hoch“, weil Profile falsch konfiguriert sind.
  • Inkonsequenz: Markierungen werden an manchen Übergängen akzeptiert, an anderen gelöscht – QoS wird unvorhersehbar.

Die Trust Boundary löst genau das, indem sie festlegt: Wer darf welche Markierungen setzen, und wie wird überschüssiger oder unerlaubter Traffic behandelt?

Was bedeutet Trust Boundary im Telco-Netz konkret?

Eine Trust Boundary ist eine definierte Netzgrenze, an der Markierungen geprüft und entschieden werden. Im Telco-Umfeld ist sie typischerweise an den Punkten platziert, an denen „fremder“ Traffic ins Provider-Netz eintritt oder Domänen wechseln.

  • UNI (User Network Interface): Übergabe zum Endkunden/Unternehmen.
  • NNI (Network-to-Network Interface): Übergabe zu anderen Carriern, Partnern, Wholesale-Kunden oder Cloud-Interconnects.
  • Provider Edge (PE): Service-Edge, an dem Kundenverkehr in den Backbone überführt und profiliert wird.
  • Managed CPE: Provider-kontrolliertes Kundengerät, das Markierung zuverlässig setzen und durchsetzen kann.

An der Trust Boundary findet typischerweise eine Kombination aus Klassifizierung, Markierung/Remarking und Profilierung statt. Dahinter wird die Klasse im Netz konsistent gequeued und geschedult.

Die drei Trust-Modelle: Untrusted, Trusted, Conditional Trust

In der Praxis haben sich drei Grundmodelle etabliert. Sie unterscheiden sich darin, wie viel Vertrauen der Provider dem eingehenden Traffic schenkt.

Untrusted: Markierungen werden nicht akzeptiert

Im Untrusted-Modell werden Kundenmarkierungen ignoriert oder auf Default gesetzt. Das ist typisch für Retail-Internet und für Umgebungen, in denen der Provider die Endgeräte nicht kontrolliert.

  • Vorteile: sehr robust gegen Missmarkierung und Missbrauch; einfache Betriebslogik.
  • Nachteile: echte Premium-Services sind schwerer umzusetzen; QoS basiert stärker auf Provider-seitiger Serviceerkennung oder auf getrennten Servicepfaden.

Untrusted ist oft die richtige Wahl, wenn der Kunde weder kontrollierte Endgeräte noch klare QoS-Vereinbarungen hat.

Trusted: Markierungen werden übernommen

Im Trusted-Modell akzeptiert der Provider die eingehenden Markierungen. Das ist nur dann sinnvoll, wenn die Quelle verlässlich ist – beispielsweise ein managed Voice-Gateway, ein SBC, ein Provider-eigenes IMS-Element oder ein strikt kontrolliertes Enterprise-LAN.

  • Vorteile: End-to-End QoS ist einfach, Markierungen können durchgängig genutzt werden.
  • Nachteile: hohes Risiko, wenn Vertrauen falsch gesetzt ist; Premium-Inflation kann das Netz destabilisieren.

Trusted ist in Provider-Netzen selten „pauschal“ und eher für definierte, kontrollierte Domänen geeignet.

Conditional Trust: Vertrauen mit Budget und Regeln

Conditional Trust ist im Telco-Alltag häufig der beste Kompromiss. Markierungen werden akzeptiert, aber nur innerhalb klarer Profile. Überschuss wird remarkt oder begrenzt, und Premium-Klassen werden gegen Missbrauch geschützt.

  • Vorteile: Premium-Services möglich, Netz bleibt stabil, Missmarkierung wird abgefangen.
  • Nachteile: erfordert saubere Profilierung, Monitoring und Templates; mehr Betriebsaufwand als Untrusted.

Conditional Trust ist besonders wichtig, wenn Sie Business-Voice, UC-Video oder Mobile Backhaul mit SLAs anbieten.

QoS-Markierungen: DSCP, CoS und MPLS-TC an der Grenze richtig handhaben

Eine Trust Boundary muss nicht nur „ja/nein“ entscheiden, sondern auch zwischen Markierungswelten übersetzen. In Telco-Netzen existieren oft mehrere Ebenen:

  • DSCP: IP-Markierung, die in DiffServ-Klassen übersetzt wird (EF für Voice, AF für Video etc.).
  • CoS/802.1p: L2-Markierung in VLAN-Tags, häufig relevant im Access/Metro-Ethernet.
  • MPLS-TC/EXP: im MPLS/SR-Core oft die Grundlage für Core-Queuing.

Eine professionelle Trust Boundary definiert daher ein Mapping: Welche DSCP/CoS-Werte werden akzeptiert, auf welche internen Klassen werden sie gemappt, und wie werden sie im Backbone (TC/EXP) umgesetzt?

Warum „Trust DSCP“ allein nicht reicht: Klassifizierung und Normalisierung

Selbst im Trusted- oder Conditional-Trust-Modell ist es selten sinnvoll, DSCP einfach 1:1 durchzuwinken. In der Praxis wollen Provider ein kleines Klassenmodell (z. B. 5–7 Klassen), während Kunden sehr viele DSCP-Varianten nutzen könnten. Deshalb wird an der Trust Boundary oft normalisiert:

  • DSCP-Reduktion: Viele Kundencodes werden auf wenige Providerklassen gemappt.
  • Service-Orientierung: Voice Media wird in EF/LLQ abgebildet, Video in AF-Klasse, Signalisierung separat.
  • Konformitätsprüfung: Nur definierte DSCP-Werte sind zulässig; alles andere wird auf Best Effort gesetzt.

Das reduziert Komplexität und verhindert, dass seltene oder exotische Markierungen den Betrieb stören.

Profilierung an der Trust Boundary: Policing, Remarking und Shaping

Trust ohne Profilierung führt fast immer zu Premium-Inflation. Deshalb ist Profilierung an der Netzgrenze ein zentrales Element. Dabei geht es nicht nur um „Rate Limits“, sondern um die Stabilität der QoS-Klassen.

Policing: Durchsetzen und schützen

  • Wofür: Schutz vor Missbrauch, Durchsetzung von Produktprofilen, Fairness zwischen Kunden.
  • Risiko: harte Drops schaden Echtzeit; deshalb Voice möglichst nicht droppen.

Remarking: Überschuss kontrolliert abwerten

  • Wofür: Premium bleibt stabil, Überschuss läuft als Best Effort oder mit höherer Drop-Precedence weiter.
  • Vorteil: weniger zerstörerisch als Drop, besonders für Video.

Shaping: Bursts glätten

  • Wofür: Stabilität an rate-limitierten Übergängen, Reduktion von Drop-Clustern, Microburst-Entschärfung.
  • Wichtig: Shaping so einsetzen, dass Voice in einer Low-Latency-Queue nicht „mitgepuffert“ wird.

Ein typisches Telco-Muster ist: Ingress-Policing/Remarking für Governance und Egress-Shaping für Stabilität.

Typische Trust-Boundary-Szenarien im Provider-Netz

Die richtige Trust-Strategie hängt stark vom Produkt und vom Zugang ab.

Retail-Internet (Untrusted)

  • Markierungen: meist neutralisiert.
  • Premium: wenn angeboten, dann über getrennte Service-Mechanismen (z. B. managed Voice, separate CPE-Policies).

Business Access mit Managed CPE (Conditional Trust)

  • Markierungen: akzeptiert, aber auf Providerklassen normalisiert.
  • Profilierung: pro Klasse Budgets, um Premium stabil zu halten.
  • Ziel: SLA-fähige Voice/Video-Qualität.

Mobile Backhaul (Trusted/Conditional Trust)

  • Markierungen: kommen aus kontrollierten Netzkomponenten; dennoch sind Mapping und Profile kritisch.
  • Besonderheit: QCI/5QI muss sauber in DSCP/TC übersetzt werden, damit Voice/Signalisierung geschützt bleibt.

NNI/Wholesale (Conditional Trust, sehr strikt)

  • Markierungen: vertraglich definiert; nur bestimmte Klassen sind zulässig.
  • Profilierung: besonders wichtig, weil Fehler hier große Wirkung haben.

Trust Boundary und Overlays: EVPN/VXLAN, Telco Clouds, Kubernetes

In modernen Architekturen ist die Trust Boundary nicht nur ein physischer Port. Bei Overlays und Clouds entstehen neue Grenzpunkte:

  • VXLAN Tunnel Ingress: Wenn nur der innere Header markiert ist, queuet das Underlay ggf. falsch. Trust und DSCP-Propagation müssen definiert werden.
  • CNF/Kubernetes Edge: Nicht jeder Pod darf Premium markieren. Trust muss an der Host-/CNI-Grenze gesetzt werden.
  • Service Mesh/Proxies: Zusätzliche Hops können Markierungen überschreiben oder QoS-Wirkung ändern.

Das Prinzip bleibt gleich: Markierung dort vertrauen, wo Kontrolle existiert, und an der Grenze normalisieren und budgetieren.

Wie falsche Trust Boundaries QoS „kaputt“ machen: typische Fehler

  • Blindes Trust im Retail: Premium-Inflation, LLQ wird überfüllt, Best Effort verhungert, Netz wird unberechenbar.
  • Überall Untrusted: Voice/Video verlieren Priorität, SLAs sind praktisch nicht erfüllbar.
  • Mapping-Drift: DSCP wird am UNI akzeptiert, aber im MPLS-Core falsch in TC gemappt; QoS-Löcher entstehen.
  • Policing auf Voice: Drops in EF erzeugen Knacken und Aussetzer – besonders bei Bursts.
  • Keine Monitoring-Sicht: Premium-Inflation bleibt unbemerkt, bis QoE kippt.

Diese Fehler sind besonders tückisch, weil sie oft erst bei Peak-Last sichtbar werden, wenn Kunden ohnehin am sensibelsten reagieren.

Monitoring an der Trust Boundary: Was Sie messen müssen

Um Trust Boundary operativ zu beherrschen, brauchen Sie Metriken, die zeigen, ob Markierungen, Profile und Klassen wirklich wie geplant genutzt werden.

  • Traffic pro Klasse: Volumen und Peaks je Klasse; wichtig zur Erkennung von Premium-Inflation.
  • Policer-Hits: welche Klassen laufen out-of-profile, bei welchen Kunden/Ports?
  • Remarking-Events: wie viel Premium wird herabgestuft?
  • Queue-Drops pro Klasse: insbesondere in Voice/Video-Klassen; Drops in Voice sind kritisch.
  • QoE-KPIs: MOS/R-Faktor, Audio-Interruptions, Video-Freeze-Events (bei managed Services) als Kundensicht.

Ein bewährter Betriebsstandard ist: Wenn die Voice-Klasse Drops zeigt oder Premium-Volumen sprunghaft steigt, wird die Trust Boundary als erstes geprüft.

Praxis-Blueprint: Trust Boundary in wenigen Schritten sauber designen

  • Klassenmodell festlegen: wenige, klare Providerklassen (Voice EF, Video AF, Control, Best Effort, Background).
  • Trust-Strategie pro Produkt: Retail untrusted, Business conditional trust, Mobile/Wholesale streng vertraglich.
  • Normalisierung definieren: Kundendaten in Providerklassen mappen, exotische DSCPs eliminieren.
  • Profilierung implementieren: Budgets pro Klasse (Policing/Remarking), Shaping an rate-limitierten Übergängen.
  • End-to-End Mapping: DSCP → CoS → MPLS-TC konsistent über Access, Metro, Core.
  • Monitoring operationalisieren: Traffic pro Klasse, Policer-Hits, Remarking, Drops, QoE-Korrelation.

Mit diesem Vorgehen wird QoS-Markierung an der Netzgrenze zu einem kontrollierten Prozess – statt zu einem „Hoffen, dass DSCP durchkommt“.

Häufige Fragen zur Trust Boundary im Telco-Netz

Warum kann ich DSCP nicht einfach immer durchlassen?

Weil Sie damit das Netz für Missmarkierung öffnen. Premium-Klassen sind nur dann wirksam, wenn sie knapp und profiliert bleiben. Blindes Trust führt zu Premium-Inflation und kann das Netz unter Last destabilisieren.

Ist Untrusted nicht „gegen QoS“?

Nein. Untrusted ist eine Sicherheits- und Stabilitätsentscheidung. In Retail-Internetprodukten ist es oft sinnvoll, Markierungen zu neutralisieren und Premium nur in kontrollierten, managed Services anzubieten. QoS funktioniert dann über Provider-seitige Policies, nicht über Kundensignale.

Was ist der wichtigste Erfolgsfaktor für eine gute Trust Boundary?

Konsistenz: ein klares Klassenmodell, sauberes Mapping (DSCP/CoS/MPLS-TC), profilierte Budgets und Monitoring. Wenn diese vier Elemente stimmen, bleibt Premium wirklich Premium, Best Effort fair und QoS im Provider-Netz operativ beherrschbar.

Related Articles