SRv6 QoS ist für viele Provider und große Enterprise-Netze ein aktuelles Thema, weil SRv6 nicht nur Traffic Engineering modernisiert, sondern auch die Frage neu stellt: Wie setzt man Hop-by-Hop Policies im IPv6-basierten Segment Routing um – und wo liegen die praktischen Grenzen? In klassischen MPLS-Backbones ist QoS seit Jahren etabliert: DSCP wird am Edge klassifiziert, im Core über TC/EXP in Queues übersetzt, und PHBs (Per-Hop Behaviors) sind relativ klar an Queueing/Scheduling gekoppelt. SRv6 verschiebt die Mechanik in einen IPv6-Kontext: Traffic wird über einen SRv6-Header (Segment Routing Header) und SIDs gesteuert, und QoS muss weiterhin zuverlässig an jedem Hop wirken – über Marking, Trust Boundaries, Queues, Shaping und AQM/ECN. Gleichzeitig bringt SRv6 neue Realitäten mit: zusätzlicher Header-Overhead, strengere MTU-Disziplin, unterschiedliche Hardware-Offload-Fähigkeiten, komplexere Klassifizierung (inner vs. outer Header) und die Frage, wie Policies entlang des Pfades konsistent bleiben, wenn Traffic über verschiedene Domänen, Linecards oder Plattformgenerationen läuft. Wer SRv6 QoS professionell plant, denkt deshalb nicht nur in „wir markieren DSCP“, sondern in Hop-by-Hop Policies, Congestion Domains, Encapsulation-Effekten und messbarer Betriebsfähigkeit.
SRv6 kurz eingeordnet: Routing-Mechanik neu, QoS-Prinzipien bleiben
SRv6 ersetzt nicht die Grundprinzipien von QoS. Auch in SRv6-Netzen gilt: QoS wirkt dort, wo Congestion entsteht, und sie wird durch Marking, Queueing, Scheduling, Shaping und Policing umgesetzt. Was sich ändert, ist der Transport- und Steuerlayer: Der Pfad wird über SRv6-SIDs beeinflusst, und Pakete tragen zusätzliche Header-Information. Dadurch verschieben sich Engpässe und Failure Patterns: MTU/Fragmentierung wird häufiger relevant, und die Frage „welcher Header wird für QoS ausgewertet?“ wird wichtiger. Außerdem ist SRv6 in vielen Netzen noch in Migration: MPLS und SRv6 koexistieren, wodurch Mappings und Trust Boundaries besonders sauber sein müssen.
- Hop-by-Hop bleibt: Queues und Scheduler arbeiten weiterhin pro Interface/Hop.
- Encapsulation kommt dazu: SRH-Overhead beeinflusst MTU, Burstiness und effektive Rates.
- Pfadsteuerung ist flexibler: Policies können Traffic gezielt durch bestimmte Congestion Domains führen.
- Betrieb ist heterogener: Offload-Fähigkeiten und Feature-Parität variieren zwischen Plattformen.
Hop-by-Hop Policies: Was man darunter in SRv6 QoS versteht
Hop-by-Hop Policies sind die Regeln, die an jedem Router-Hop entscheiden, wie ein Paket behandelt wird. In SRv6 sind das typischerweise dieselben Policy-Bausteine wie in IP/MPLS, aber mit klarer Festlegung, welcher Traffic-Selector gilt: DSCP im Outer IPv6-Header, DSCP im Inner Header (bei Encapsulation), Flow-Labels, Interface-/VRF-Kontext oder SRv6-spezifische Klassifizierungsmerkmale. „Praktische Grenzen“ beginnen dort, wo diese Selektoren nicht konsistent verfügbar sind, wo Hardware nur einen Teil davon in der Fast Path Pipeline auswerten kann oder wo Encapsulation dazu führt, dass Marking an der falschen Stelle betrachtet wird.
- Classification: Welche Pakete gehören zu welcher Klasse (Voice, Video, Business, BE, Bulk)?
- Marking: Welche DSCP-Werte werden gesetzt/akzeptiert (Trust Boundary)?
- Queueing/Scheduling: Welche Queue, welches Gewicht/Limit, welche Drop-Policy?
- Shaping/Policing: Wo wird Burstiness geglättet oder Profile durchgesetzt?
Inner vs. Outer DSCP: Die wichtigste SRv6-QoS-Entscheidung
Bei SRv6-Encapsulation stellt sich zwangsläufig die Frage, welche DSCP-Markierung für die Hop-by-Hop Behandlung verwendet wird. Pakete haben häufig einen Inner Header (ursprünglicher Traffic) und einen Outer IPv6 Header (Transport), zusätzlich ggf. einen SRH. Wenn Router im Core nur den Outer Header klassifizieren, müssen Sie sicherstellen, dass die Serviceklasse in den Outer DSCP korrekt übernommen wird (Copy/Propagation). Wenn Router (oder bestimmte Pfade) stattdessen Inner DSCP auswerten, benötigen Sie konsistente Regeln, die das netzweit stabil halten. In der Praxis ist eine klare, netzweite Policy entscheidend, weil Mischformen zu QoS-Löchern führen: Voice ist markiert, aber im Core als Best Effort behandelt.
- Outer-DSCP-Ansatz: Core klassifiziert auf Outer DSCP; erfordert saubere DSCP-Copy am Encapsulation-Edge.
- Inner-DSCP-Ansatz: Core nutzt Inner DSCP; erfordert Plattform-/Pipeline-Support, oft komplexer.
- Hybrid-Risiko: wenn unterschiedliche Routergenerationen unterschiedlich auswerten, entsteht Drift.
Trust Boundaries in SRv6: Wo Markierungen akzeptiert oder normalisiert werden
SRv6 ändert nichts an der Grundwahrheit: In Multi-Tenant-Umgebungen sind kundenseitige Markierungen nicht automatisch vertrauenswürdig. Im SRv6-Kontext wird das sogar wichtiger, weil die Edge-Entscheidung (Encapsulation) häufig auch die Marking-Propagation steuert. Eine saubere Trust Boundary sitzt daher am SRv6-Ingress (Edge/Border), wo Servicekontext bekannt ist. Dort wird eine Allowlist durchgesetzt, Kunden-Markings werden auf Provider-Standardwerte gemappt, und Budgets pro Klasse werden enforced (Policing/Degradation). Das Ziel: Premiumklassen schützen, ohne echte Echtzeitdienste zu beschädigen.
- Allowlist: nur definierte DSCP-Werte werden akzeptiert; Rest wird normalisiert.
- Remarking: Kundenwerte werden auf interne Klassen gemappt, bevor sie in Outer DSCP propagiert werden.
- Profilbudgets: pro Service/VRF/Subscriber Limits für Realtime-Klassen (besonders wichtig bei strict priority).
- Auditierbarkeit: Remarking-/Policer-Zähler als Nachweis, dass Trust-Regeln greifen.
Queueing und Scheduling: SRv6 braucht das gleiche Disziplinmodell wie MPLS
Ob MPLS oder SRv6: Echtzeitqualität entsteht am Engpass durch Queueing und Scheduling. In SRv6-Netzen ist die Versuchung groß, alles über „Policy Steering“ zu lösen. Das hilft gegen Hotspots, ersetzt aber nicht die Notwendigkeit, Warteschlangenverzögerung und Drops zu kontrollieren. Ein bewährtes Modell bleibt: Voice in eine limitierte LLQ, Video in eine gewichtete Echtzeitklasse, Business in eine bevorzugte Klasse, Best Effort mit AQM/ECN gegen Bufferbloat, Bulk nachrangig. Entscheidend ist, dass diese PHBs auf allen relevanten Linktypen identisch wirken und dass Queue-Limits so gesetzt sind, dass Bufferbloat nicht die Latenz zerstört.
- LLQ für Voice: strikt priorisiert, aber strikt begrenzt; sonst Starvation-Risiko.
- Gewichtete Klassen: Video/Business stabil bedienen, ohne Best Effort zu kollabieren.
- AQM/ECN: Best Effort stabilisieren, RTT-Spitzen senken, Throughput erhalten.
- Queue-Limits: Echtzeitqueues kurz halten, damit Jitter niedrig bleibt.
Praktische Grenze 1: SRv6-Overhead, MTU und Fragmentierung
SRv6 fügt Overhead hinzu: Outer IPv6 Header plus SRH und SIDs. Das reduziert die effektive Nutzlast pro Paket und erhöht das Risiko für MTU-Probleme. Für QoS ist das doppelt relevant: Erstens kann Fragmentierung oder PMTUD-Fehlverhalten zu Drops führen, die bei Echtzeit sofort spürbar sind. Zweitens erhöht Overhead die effektive Leitungslast – Budgets für Echtzeitklassen müssen das berücksichtigen, sonst treffen Policer/Queue-Limits „zu früh“. In der Praxis ist MTU-Disziplin daher ein Kernbestandteil von SRv6 QoS: MSS-Clamping, klare MTU-Standards pro Domäne und Tests mit realen Encapsulation-Stacks.
- PMTUD-Risiken: „zu große“ Pakete führen zu Drops oder Fragmentierung – beides schlecht für Echtzeit.
- Effektive Bitrate steigt: Overhead erhöht die Rate in Engpasslinks; QoS-Budgets müssen angepasst werden.
- RTP/Voice: kleine Pakete sind overhead-sensitiv; SRv6 wirkt prozentual stärker.
Praktische Grenze 2: Hardware-Offload und Feature-Parität
SRv6 ist stark von Hardware-Offload abhängig, wenn Sie große Durchsätze und niedrige Latenzen im Core liefern wollen. Nicht jede Plattform unterstützt SRH-Verarbeitung, Klassifizierung und QoS-Mapping im Fast Path gleich gut. Das führt zu einem typischen Betriebsrisiko: Auf einigen Routern funktioniert Class-Aware Behandlung sauber (Outer DSCP, konsistente Queues), auf anderen fällt Traffic in generische Pfade oder wird anders klassifiziert. In SRv6 QoS müssen Sie daher Plattform- und Linecard-Grenzen als „praktische Grenzen“ akzeptieren und Designs so bauen, dass Mixed-Hardware nicht zu QoS-Löchern führt.
- Uneinheitliche Pipeline: manche Geräte klassifizieren nur Outer DSCP, andere können Inner Header tiefer auswerten.
- SRH-Verarbeitung: kann CPU- oder Slow-Path-lastig werden, wenn Offload fehlt.
- QoS-Feature-Gaps: Queue-Anzahl, AQM/ECN-Fähigkeit und Telemetrie unterscheiden sich.
Praktische Grenze 3: Hop-by-Hop Policy-Drift in Multi-Domain oder Multi-Vendor Netzen
SRv6 erleichtert Pfadsteuerung, aber es erhöht die Gefahr von Policy-Drift, wenn QoS-Profile nicht strikt standardisiert sind. Drift zeigt sich typischerweise so: DSCP/Queues sind in Region A anders als in Region B, oder nach einem Upgrade ändert sich Default-Mapping. Deshalb ist Governance besonders wichtig: zentrale Klassenmodelle, Template-Renderings pro Plattform, Rezertifizierung und Audits auf Queue-Health (Delay/Drops) sowie auf Marking-Integrität (Ingress/Egress DSCP).
- Standard-Tables: DSCP- und Queue-Mappings zentral definieren, nicht „pro Team“.
- Rezertifizierung: regelmäßig prüfen, ob Policies nicht nur vorhanden, sondern wirksam sind.
- Ausnahmen managen: Exception Register mit Owner und Ablaufdatum, sonst wird Drift permanent.
Hop-by-Hop Policies mit SRv6 Steering verbinden: Class-Aware Pathing in der Praxis
SRv6 ermöglicht, Traffic gezielt durch definierte Congestion Domains zu führen. Für QoS ist das wertvoll, wenn Sie bekannte Hotspots umgehen oder Premiumklassen auf stabilere Pfade legen wollen. Praktisch funktioniert das nur, wenn Steering und QoS-Classes aligned sind: Eine Voice-Klasse, die auf einen „Premium-Pfad“ gesteuert wird, muss entlang dieses Pfades auch tatsächlich die Voice-PHB bekommen – sonst steuern Sie nur „optisch“. Ein bewährtes Muster ist daher: pro Klasse ein Pfadprofil (Primary/Secondary/Fallback), dazu klare Hop-by-Hop PHBs, Shaping an Übergängen und Telemetrie, die Pfadwechsel und QoE-Effekte korreliert.
- Premiumklassen: low-latency und stabile Pfade, wenige Hotspots, planbare Failover-Pfade.
- Best Effort/Bulk: kapazitätsstarke Pfade, darf eher „umwegig“ sein.
- Guardrails: Limits, Shaping und Monitoring verhindern, dass Premiumklassen durch Fehlmarking wachsen.
Messbarkeit: SRv6 QoS ohne Telemetrie ist nicht betreibbar
SRv6 QoS muss auf zwei Ebenen gemessen werden: Hop-by-Hop (Queue-Delay, Queue-Drops, AQM/ECN-Marks pro Klasse) und Pfad-/Policy-Ebene (welche SRv6-Policies sind aktiv, wie oft wird umgelenkt, welche Links sind hot). Zusätzlich sollten Sie service-nahe KPIs für Echtzeit (RTP-Loss/Jitter, MOS/R-Faktor-Schätzungen, sofern verfügbar) in die Korrelation aufnehmen. Entscheidend sind kurze Zeitfenster und Perzentile, weil SRv6-Probleme oft in Peak-Phasen oder bei Pfadwechseln sichtbar werden.
- Queue-Delay p95/p99: Frühindikator für Jitterprobleme.
- Class Drops: Drops in Voice/Control-Klassen sind kritische Events.
- Policy Events: Pfadwechsel, Fallbacks, Maintenance-Umleitungen sichtbar machen.
- MTU-Signale: Fragmentierung/PMTUD-Probleme detektieren, bevor Echtzeit leidet.
Typische Failure Patterns und praktische Grenzen im Alltag
SRv6 QoS scheitert selten an der Idee, sondern an wiederkehrenden Mustern: MTU/Overhead wird nicht berücksichtigt, Outer/Inner DSCP ist inkonsistent, Hardware-Offload fehlt auf Teilstrecken, oder Policies sind zwar definiert, aber die Engpässe liegen an Übergängen (Interconnects, Aggregation), wo Shaping und HQoS fehlen. Diese Grenzen lassen sich beherrschen, wenn sie von Anfang an in das Design aufgenommen werden.
- Voice leidet nach SRv6-Einführung: Overhead reduziert Headroom, Policer/LLQ zu knapp dimensioniert.
- QoS-Löcher: manche Router klassifizieren anders (Inner vs. Outer), DSCP-Copy inkonsistent.
- Pfadwechsel erzeugt Jitter: Policies schalten zu häufig um; Stabilitätskriterien fehlen.
- Interconnect-Engpass: Core ist sauber, aber Übergang überlastet; Shaping/AQM fehlen am Rand.
- Mixed Hardware: SRH-Verarbeitung im Slow Path; Latenzspitzen unter Last.
Blueprint: SRv6 QoS robust und realistisch umsetzen
Ein praxiserprobtes Vorgehen beginnt mit klaren Grundlagen: schlankes Klassenmodell, DSCP-Strategie, Trust Boundaries am SRv6-Ingress, und eine eindeutige Entscheidung für Outer-vs-Inner DSCP als Klassifizierungsbasis. Danach wird MTU/Overhead end-to-end geplant (Standards, MSS, Tests), und PHBs werden netzweit konsistent umgesetzt (limitierte LLQ für Voice, gewichtete Klassen für Video/Business, AQM/ECN für Best Effort). Anschließend werden SRv6-Policies eingeführt, die Congestion Domains berücksichtigen und Class-Aware Steering ermöglichen, ohne instabile Pfadwechsel zu verursachen. Shaping und HQoS werden an Übergängen platziert, wo Congestion real entsteht. Abschließend wird Telemetrie aufgebaut, die Queue-Health, Policy-Events und QoE-KPIs korreliert. So entsteht SRv6 QoS, das Hop-by-Hop Policies sauber umsetzt und gleichzeitig die praktischen Grenzen – Overhead, Offload, Drift und Interconnect-Realität – von Anfang an beherrscht.
