Trust Boundary Design ist einer der wichtigsten Bausteine jeder QoS- und DSCP-Strategie, weil er entscheidet, ob Markierungen im Netz eine verlässliche Bedeutung haben oder nur „Wunschdenken“ sind. In Telco- und großen Enterprise-Umgebungen ist es grundsätzlich riskant, DSCP/CoS-Markierungen ungeprüft zu übernehmen: Endgeräte, Kunden-CPEs, Applikationen oder Drittanbieter können Pakete beliebig markieren – absichtlich oder aus Fehlkonfiguration. Wenn ein Netz solche Markierungen blind vertraut, werden Premium-Queues schnell überlaufen, Echtzeitklassen verlieren ihre Wirkung und SLAs werden praktisch nicht mehr kontrollierbar. Genau deshalb definiert man Trust Boundaries: klare Stellen im Netz, an denen Markierungen akzeptiert, normalisiert oder überschrieben werden. Ein gutes Trust Boundary Design verbindet Sicherheitsdenken (Missbrauch verhindern), Engineering (Congestion kontrollieren) und Betrieb (messbar, auditierbar, templatefähig). In diesem Artikel geht es darum, wo Trust Boundaries sinnvoll platziert werden, wie man sie technisch umsetzt (Allowlist, Remarking, Policing, Shaping), welche typischen Failure Patterns auftreten und wie man das Design end-to-end so aufstellt, dass QoS-Klassen konsistent bleiben – von Access über Aggregation bis zum Core und Interconnect.
Was eine Trust Boundary ist – und was sie nicht ist
Eine Trust Boundary ist ein definierter Übergangspunkt, an dem das Netz entscheidet: „Ich vertraue dieser Markierung“ oder „Ich setze sie auf meinen Standard zurück“. Das ist keine philosophische Frage, sondern eine konkrete Policy: Welche DSCP-Werte sind erlaubt? Für welche Quelle (Kunde, VLAN, VRF, Subscriber) gelten sie? Welche Profile (Bandbreitenbudgets) sind damit verbunden? Und was passiert bei Abweichungen? Wichtig ist: Trust ist nie „global“, sondern immer kontextabhängig. Ein managed Voice-VLAN im Unternehmensnetz kann vertrauenswürdig sein; ein Internetanschluss eines beliebigen Kunden ist es nicht.
- Trust: Markierungen werden akzeptiert und in interne Klassen gemappt.
- Conditional Trust: Trust nur für definierte Quellen/Services, sonst Normalisierung.
- No Trust: Markierungen werden ignoriert, Pakete werden neu markiert.
- Durchsetzung: Trust Boundaries brauchen Policer/Remarking, sonst sind sie wirkungslos.
Warum Trust Boundaries im Provider-Netz zwingend sind
Provider-Netze sind Multi-Tenant-Umgebungen: Viele Kunden teilen sich dieselben Ressourcen. Ohne Trust Boundaries kann ein einzelner Kunde (oder ein falsch konfiguriertes Gerät) Premium-Klassen fluten, indem es seinen gesamten Verkehr als EF (Echtzeit) markiert. Selbst wenn das Netz „korrekt priorisiert“, wird die Echtzeitklasse dann zum Best Effort – nur teurer. Zudem entsteht ein Betriebsproblem: Wenn Markierungen nicht kontrolliert werden, ist die Interpretation von KPIs wie Queue-Drops oder MOS unzuverlässig, weil man nicht mehr weiß, welcher Traffic wirklich zur Klasse gehört.
- Missmarking: absichtlich oder unabsichtlich – beides kommt vor.
- Premium-Queue Inflation: Echtzeitklasse wird zu groß, andere Klassen verhungern.
- SLA-Unschärfe: ohne definierte Trust-Regeln ist nicht klar, was ein SLA überhaupt abdeckt.
- Fehlersuche: QoS-Probleme werden „mysteriös“, weil Klassen nicht mehr konsistent sind.
Das Zielbild: Wenige Klassen, klare Allowlists, eindeutige Mappings
Ein Trust Boundary Design funktioniert am besten mit einem schlanken Klassenmodell. Je weniger Klassen Sie haben, desto leichter können Sie Trust-Regeln, Mappings und Audits konsistent halten. Gleichzeitig sollte Ihre DSCP-Strategie eine Allowlist nutzen: Nur wenige DSCP-Werte sind erlaubt, alle anderen werden normalisiert. So wird verhindert, dass exotische oder vendor-spezifische DSCP-Werte unkontrolliert eine Behandlung auslösen, die im Netz niemand mehr nachvollziehen kann.
- Klassenmodell: z. B. Network Control, Voice, Video, Business, Best Effort, Scavenger.
- Allowlist: definierte DSCP-Werte (z. B. EF, ausgewählte AFs, ausgewählte CS) – Rest auf DSCP 0.
- Mappings: DSCP↔PCP↔MPLS-TC netzweit identisch, sonst entstehen QoS-Löcher.
- Budgets: pro Klasse und pro Kunde/Service – Trust ohne Budget ist unvollständig.
Wo Trust Boundaries typischerweise sitzen: Domänen und Rollen
Trust Boundaries werden dort platziert, wo Kontext und Kontrolle vorhanden sind. Im Telco-Betrieb sind das oft Service Edges: BNG/BRAS, PE-Router, Provider-Access-Edges oder Aggregation-Edges, an denen Subscriber-Information und Produktprofil bekannt sind. In Enterprise-Umgebungen sind es Access-Switches, WLAN-Controller oder Campus-Edges, an denen Identität (802.1X), VLAN-Zugehörigkeit oder Gerätetyp bekannt ist. Entscheidend ist: Der Trust Point muss in der Lage sein, Markierungen mit dem richtigen Profil zu verknüpfen.
- Provider Edge (PE): ideal, weil Service/VRF/VLAN-Kontext klar ist.
- BNG/BRAS: typisch für Broadband – Subscriber-Profile und Policys sind dort verfügbar.
- Access Switch: im Enterprise sinnvoll, wenn Endgeräte gemanagt und authentifiziert sind.
- WLAN Controller/AP: wichtig, weil DSCP zu WMM gemappt werden muss und Airtime ein Engpass ist.
- Interconnect Edge: Trust ist hier meist eingeschränkt und vertraglich geregelt.
Trust Levels definieren: „Trusted“, „Trusted with Limits“ und „Untrusted“
In der Praxis ist Trust selten binär. Viele Betreiber nutzen abgestufte Trust Levels, die sich an Produkt- und Sicherheitsanforderungen orientieren. Ein „Trusted“-Service könnte ein managed SIP-Trunk mit definierten Markings sein. „Trusted with Limits“ bedeutet: Marking wird akzeptiert, aber per-Class Policer begrenzen die Nutzung. „Untrusted“ bedeutet: Marking wird ignoriert oder neu gesetzt, etwa bei unkontrollierten Internetkunden.
- Trusted: Marking akzeptieren, nur minimale Normalisierung; geeignet für kontrollierte Managed Services.
- Trusted with Limits: Marking akzeptieren, aber streng budgetieren (Policing/Remarking).
- Untrusted: Marking neu setzen; geeignet für öffentliche/unkontrollierte Anschlüsse.
Technische Umsetzung: Allowlist, Remarking, Policing und Shaping
Ein Trust Boundary ist nur dann wirksam, wenn er technisch durchgesetzt wird. Das besteht typischerweise aus vier Bausteinen: Erstens eine Allowlist, welche DSCP/PCP-Werte überhaupt akzeptiert werden. Zweitens Remarking, um unerlaubte Markierungen zu normalisieren oder in zulässige Klassen zu übersetzen. Drittens Policing, um die Nutzung pro Klasse (z. B. EF) zu begrenzen. Viertens Shaping, um Congestion kontrollierbar zu machen und Mikrobursts zu glätten, damit Echtzeitklassen nicht durch Drop-Bursts beschädigt werden.
- Allowlist: nur definierte DSCP-Werte passieren; alles andere wird auf Best Effort gesetzt.
- Remarking: DSCP-Werte werden auf interne Standardwerte gemappt.
- Policing: pro Klasse begrenzen (z. B. EF max. X kbit/s pro Kunde), Überschreitungen remarken oder droppen.
- Shaping: vor allem am WAN-Edge, um die Queue in den eigenen Einflussbereich zu holen.
Remarking-Strategien: „Drop“, „Degrade“ oder „Normalize“
- Normalize: unbekannte DSCP-Werte werden zu DSCP 0, damit sie Best Effort sind.
- Degrade: Überschreitungen werden in eine niedrigere Klasse ummarkiert (häufig besser als Drop bei Echtzeit).
- Drop: harte Durchsetzung, sinnvoll gegen Missbrauch; bei Echtzeit jedoch besonders spürbar.
Warum EF besonders streng behandelt werden muss
EF (Expedited Forwarding) ist in vielen Designs die Echtzeitklasse für Voice Media (RTP). EF hat eine besondere Eigenschaft: Es wird häufig mit strikter Priorität (LLQ) bedient. Wenn EF nicht limitiert und nicht geschützt ist, kann es das gesamte System destabilisieren. Deshalb ist EF im Trust Boundary Design fast immer „Trusted with Limits“: Marking wird akzeptiert, aber Bandbreitenbudgets pro Kunde/Service sind strikt, und unerlaubte EF-Markierungen werden normalisiert.
- LLQ: strikte Priorität, deshalb gefährlich ohne Limit.
- Profilbudgets: EF pro Kunde/Service begrenzen, sonst Missbrauch möglich.
- Auditfähigkeit: EF-Nutzung und EF-Drops müssen messbar sein, sonst ist SLA-Qualität nicht belegbar.
Trust Boundaries über Layer hinweg: DSCP, PCP, MPLS-TC und Overlays
In Telco-Netzen endet Trust nicht bei DSCP. Häufig müssen Markierungen zwischen Layern übersetzt werden: DSCP im IP-Header, PCP (802.1p) im Ethernet-Tag und MPLS-TC im Label-Stack. Zusätzlich kommen Overlays wie IPsec, GRE oder SD-WAN hinzu, bei denen Markierungen in den Outer Header kopiert werden müssen. Ein gutes Trust Boundary Design definiert deshalb nicht nur „welche DSCPs sind erlaubt“, sondern auch, wie diese Werte an jedem Übergang gemappt werden und wo das Netz Markierungen neu setzt.
- DSCP↔PCP: wichtig in Metro-Ethernet und Aggregations-Switching.
- DSCP↔MPLS-TC: entscheidend im Core, damit Klassen konsistent bleiben.
- Overlay Copy: Inner-to-Outer Markings, sonst sieht das Underlay Best Effort.
- Interconnect: oft eigene Trust-Profile, da die Kontrolle domänenübergreifend begrenzt ist.
Failure Patterns: Was passiert, wenn Trust Boundaries falsch gesetzt sind
Fehlplatzierte oder inkonsistente Trust Boundaries führen zu typischen Problemen. Entweder wird zu viel vertraut (Premium-Queues werden überflutet), oder es wird zu wenig vertraut (Echtzeit kommt als Best Effort an). Besonders häufig ist auch „Partial Trust“ ohne Budget: Marking wird akzeptiert, aber nicht begrenzt. Das sieht zunächst gut aus, bis Busy Hour oder ein Fehlverhalten die Echtzeitklasse sprengt.
- Premium-Queue Flooding: zu großzügiger Trust, EF unlimitiert → LLQ wird Best Effort.
- QoS-Löcher: Marking wird an einem Übergang genullt oder falsch gemappt.
- Policer-Drops in Echtzeit: Budgets zu knapp oder falsch modelliert; hörbare Aussetzer.
- Asymmetrische Qualität: Trust/Remarking nur in eine Richtung → Einweg-Audio oder einseitige Qualitätseinbrüche.
- Failover bricht QoS: Backup-Pfad ohne gleiche Trust-/QoS-Policies.
Messbarkeit und Audit: Trust Boundary Design muss nachweisbar sein
Ein Trust Boundary ist ein Governance-Element und muss auditierbar sein. Das bedeutet: Sie sollten nachweisen können, welche Markierungen akzeptiert werden, wie oft remarkt wird, wo Policer greifen und ob Echtzeitklassen Drops oder Queue-Delay sehen. Besonders wertvoll sind Zähler für Remarking und Policing, DSCP-Verteilungen pro Interface sowie Queue-KPIs pro Klasse. So wird Trust nicht zu einer Annahme, sondern zu einem messbaren System.
- DSCP-Distribution: welche Markings treten tatsächlich auf, wo gibt es Ausreißer?
- Remarking Counters: wie viele Pakete wurden normalisiert oder degradiert?
- Policer Counters: wo werden Profile überschritten, ist das erwartbar oder ein Problem?
- Queue-Health: Queue-Delay und Drops pro Klasse zeigen, ob Trust-Design QoS stabil hält.
Blueprint: Trust Boundary Design als wiederholbares Muster
Ein robustes Trust Boundary Design folgt einem klaren Ablauf. Zuerst wird ein schlankes Klassenmodell definiert und eine DSCP-Allowlist festgelegt. Danach werden Trust Levels pro Produkt und Schnittstelle entschieden: Managed Services können Markings in definierten Grenzen liefern, unkontrollierte Zugänge werden normalisiert. Anschließend werden Remarking- und Policer-Regeln implementiert, die EF/AF-Budgets durchsetzen, und Shaping wird an Engpässen platziert, damit Congestion kontrollierbar bleibt. Parallel werden Mappings zu PCP/MPLS-TC/Overlays verbindlich dokumentiert und per Templates ausgerollt. Abschließend wird das Ganze über Telemetrie und Audits abgesichert: Remarking-Zähler, DSCP-Verteilungen, Queue-Delay und Drops pro Klasse. So entsteht ein Trust Boundary Design, das Markierungen dort akzeptiert, wo es sicher und sinnvoll ist – und sie dort überschreibt, wo sie das Netz destabilisieren würden.
