SRv6 Topology Patterns sind für Telcos und Provider interessant, weil Segment Routing über IPv6 (SRv6) Pfadsteuerung, Service-Encapsulation und teilweise auch Service-Chaining in einem konsistenten, IP-zentrierten Modell vereinen kann. Gleichzeitig bringt SRv6 eine praktische Realität mit sich, die in Carrier-Grade Designs nicht ignoriert werden darf: den SRH Overhead (Segment Routing Header Overhead) und die daraus folgenden Anforderungen an MTU, Kapazität, Hardware-Fähigkeiten und Observability. Genau an dieser Stelle kommen Micro-SIDs ins Spiel: Sie zielen darauf ab, den Overhead zu reduzieren, indem mehrere Segmente effizienter kodiert werden, sodass SRv6 auch in Umgebungen mit strengen MTU- und Effizienzanforderungen attraktiv bleibt. In der Praxis steht jedoch nie nur die Technik im Raum, sondern auch die Migration: Wie führt man SRv6 ein, ohne bestehende MPLS- oder SR-MPLS-Domänen zu destabilisieren? Wie plant man Topologie-Patterns, die über Jahre wachsen? Und wie verhindert man Komplexitäts-Explosion durch zu viele Sonderfälle? Dieser Artikel erklärt SRv6-Topologiemuster, den SRH-Overhead samt Designfolgen, die Idee hinter Micro-SIDs und praxisnahe Migrationspfade für Telco-Netze.
SRv6 im Telco-Umfeld: Was sich gegenüber SR-MPLS ändert
SRv6 nutzt IPv6 als Träger für Segment-Informationen und kann Pfadintentionen über eine Segmentliste abbilden. Im Gegensatz zu SR-MPLS, das auf MPLS-Labels basiert, trägt SRv6 Pfadinformationen in IPv6-Headern bzw. in einem SRH. Das verändert die Designprioritäten: MTU-Disziplin wird wichtiger, Overhead muss bewertet werden, und Hardware-/Forwarding-Fähigkeiten entscheiden stärker über Performance und Betriebssicherheit.
- IP-zentriertes Modell: SRv6 integriert Pfadsteuerung in ein IPv6-basiertes Transportkonzept.
- SRH als Mechanik: Segmentlisten erzeugen zusätzlichen Header-Overhead, der geplant werden muss.
- Service-Encapsulation: SRv6 kann Service-Modelle und TE-Pfade in einem konsistenten Rahmen tragen.
- Operative Konsequenz: MTU, Telemetry und Failure Handling müssen SRH-bedingte Effekte berücksichtigen.
Die zentrale Designfrage: Wo endet das Underlay, wo beginnt der SRv6-Service?
Carrier-Grade SRv6-Design trennt sauber: Das Underlay liefert stabile IPv6-Konnektivität und klare Failure Domains. SRv6-Policies und Service-Encapsulation werden an definierten Knotenrollen umgesetzt (Ingress/Service-Edge, Border/Edge-Gateways), während Transit-Knoten möglichst standardisiert bleiben.
SRv6 Topology Patterns: Wo SRv6 in Telco-Netzen typischerweise sitzt
SRv6 wird in der Praxis selten „überall gleichzeitig“ eingeführt. Stattdessen entstehen Topology Patterns entlang von Rollen und Domänen: Core/Backbone, Metro, Data Center/Edge PoPs und Übergänge zu externen Domänen. Ein robustes Design definiert pro Pattern klar, welche Knoten SRv6-Ingress/Egress sind, welche als Transit agieren und wo Policies zentral verwaltet werden.
- Core-Pattern: SRv6-fähiger Backbone, der TE-Policies und Pfadsteuerung zwischen Regionen ermöglicht.
- Metro-Pattern: Regionale Cluster, die SRv6 für kontrollierte Pfade und Service-Edges nutzen.
- DC/Edge-Pattern: SRv6 als Underlay/Overlay-Baustein für Service-Chains, Multi-Tenant-Services oder DCI-nahe Konzepte.
- Border-Pattern: Übergänge zu SR-MPLS/MPLS/Legacy-Domänen über klar definierte Gateways.
Best Practice: SRv6 als Domäne einführen, nicht als „Feature-Toggle“
Ein SRv6-Rollout ist stabiler, wenn er domänenbasiert geplant wird: klare Ingress/Egress-Punkte, klare MTU-Regeln, standardisierte Policies und ein Observability-Set, das Pfadwahl und Overhead sichtbar macht. So bleibt das Netz erklärbar und auditierbar.
SRH Overhead: Was er bedeutet und warum er Designentscheidungen dominiert
SRv6 trägt Segmentinformationen in SRH-Strukturen. Das erhöht die Paketgröße. In Telco-Netzen ist das nicht nur „ein paar Bytes“, sondern potenziell ein echter Engineering-Faktor: Größere Pakete erhöhen Bandbreitenbedarf, beeinflussen Fragmentierung/PMTUD-Verhalten und können Drops auslösen, wenn MTU nicht konsistent ist. Zudem kann Overhead die effektive Nutzdatenrate reduzieren, was bei hoher Last und knappen Kapazitäten spürbar ist.
- MTU-Anforderung: Pfade müssen eine ausreichend hohe MTU besitzen, sonst drohen Drops oder Fragmentierung.
- Kapazitätswirkung: Overhead reduziert die Netto-Nutzdatenrate (Goodput) und erhöht Linkauslastung.
- Performance-Risiko: In Hardware-Forwarding-Pipelines können größere Header komplexere Verarbeitung bedeuten.
- Troubleshooting: Fehlerbilder treten oft „sporadisch“ auf, wenn nur bestimmte Flows oder Pfade betroffen sind.
Overhead ist besonders kritisch bei langen Segmentlisten
Je mehr Segmente in einer SRv6-Policy genutzt werden, desto größer wird der SRH-Overhead. Das kann TE-Use-Cases beeinflussen: Sehr fein granulare Pfaddefinitionen (viele Segmente) sind nur dann sinnvoll, wenn MTU, Kapazität und Plattformen das zuverlässig tragen. In Telco-Designs wird daher oft versucht, Segmentlisten kurz zu halten – und hier kommen Micro-SIDs als Konzept ins Spiel.
Micro-SIDs: Idee, Nutzen und typische Einsatzmuster
Micro-SIDs zielen darauf ab, die Segmentliste effizienter zu kodieren, sodass mehrere Segmentinformationen in kompakterer Form transportiert werden können. Der praktische Nutzen liegt darin, den SRH Overhead zu reduzieren und damit SRv6 auch für Szenarien attraktiv zu machen, in denen MTU und Effizienz besonders wichtig sind. In Telco-Netzen sind das häufig Core-/Metro-Pfade mit vielen potenziellen Segmenten oder Umgebungen, in denen TE-Policies sehr granular werden.
- Overhead-Reduktion: Weniger Header-Last pro Paket, mehr Goodput und weniger MTU-Druck.
- TE-Feingranularität: Komplexere Pfadintentionen werden praktikabler, ohne Pakete unnötig aufzublähen.
- Operationaler Vorteil: Weniger MTU-Sonderfälle, weniger „mystische Drops“.
- Wichtig: Micro-SID-Einsatz muss plattformseitig und domänenweit konsistent sein.
Micro-SIDs sind kein Ersatz für gute Topologie
Auch mit Micro-SIDs gilt: SRv6 kann nur steuern, was die physische Topologie hergibt. Diversität, Störfallkapazität und klare Failure Domains bleiben Grundvoraussetzungen. Micro-SIDs sind ein Effizienzhebel, kein Mittel, fehlende Kapazität oder schlechte Trassenführung zu kompensieren.
MTU-Strategie: Der wichtigste SRv6-Betriebsschutz
In vielen SRv6-Projekten ist MTU der häufigste Stabilitätskiller. Ein robustes Design definiert daher eine end-to-end MTU-Strategie, die Underlay, Overlays, SRH und potenzielle Service-Encapsulation berücksichtigt. Diese Strategie muss nicht nur dokumentiert, sondern laufend verifiziert werden, weil einzelne Links, Optikwechsel oder Provider-Übergaben MTU-Profile verändern können.
- Netzweite Standard-MTU: Ein konsistenter Wert für Core/Metro/DC-Pfade reduziert Sonderfälle.
- PMTUD-Realität: Nicht alle Umgebungen verhalten sich ideal; Drops durch gefilterte ICMP-Fehler sind praxisrelevant.
- Guardrails: Pre-Checks, die MTU-Konsistenz vor Rollouts validieren.
- Telemetry: MTU-bezogene Drops, Fragmentierungsindikatoren und Error-Counter müssen sichtbar sein.
MTU und Störfallpfade: Nicht nur der Normalpfad zählt
Viele MTU-Probleme treten erst im Failover auf, wenn Traffic über alternative Trassen läuft. Carrier-Grade SRv6-Design prüft deshalb MTU entlang der Ersatzpfade und definiert, welche Störfallszenarien innerhalb der MTU-Strategie garantiert funktionieren müssen.
Failure Handling in SRv6-Topologien: Link, Node, Trasse und Degradation
SRv6 muss nicht nur im Normalbetrieb funktionieren, sondern im Fehlerfall stabil reagieren. Das umfasst klassische Ausfälle (Link/Node/Trasse) und die oft schwierigere Kategorie „Degradation“: Überlast, Queue-Drops, Latenzsprünge und Microbursts. SRv6-Policies sind dann hilfreich, wenn sie sowohl Resilienz- als auch Kapazitätsregeln abbilden und wenn die Umschaltlogik messbar ist.
- Link/Node Failure: Pfadwechsel muss schnell und stabil erfolgen, ohne Flapping.
- Trassenunterbrechung: Shared-Risk-Analyse entscheidet, ob Backup-Pfade wirklich unabhängig sind.
- Degradation Handling: Policies müssen Hotspots vermeiden helfen, nicht nur „down“-Events abfangen.
- Störfallkapazität: Ersatzpfade müssen Last tragen können, sonst entsteht Degradation statt Verfügbarkeit.
Resilienz ohne Reserve ist nur „Umschaltung in die Überlast“
Ein häufiger Fehler ist, Failover-Mechanismen zu perfektionieren, ohne Reserve zu planen. Dann funktioniert SRv6 formal korrekt, aber Nutzer erleben massive Drops. Daher gehören Reservequoten, Upgrade-Trigger und Serviceklassen in das SRv6-Design, nicht als nachträgliche Optimierung.
Migration: Von MPLS/SR-MPLS zu SRv6 ohne Big Bang
Telco-Netze migrieren selten in einem Schritt. Ein sinnvoller SRv6-Migrationsansatz ist domänen- und rollenbasiert: Zuerst schafft man eine stabile IPv6-Transportbasis, definiert SRv6-fähige Knotenrollen und führt SRv6 in klar begrenzten Bereichen ein. Übergänge zu MPLS/SR-MPLS werden über Border-Gateways und definierte Servicekanten gehandhabt, damit bestehende Dienste stabil bleiben.
- Phase 1: IPv6 Underlay stabilisieren (Adressierung, Domänen, MTU, Telemetry).
- Phase 2: SRv6 in einem Core-Segment oder in einer Pilotregion einführen, Policies als Templates definieren.
- Phase 3: Gateways/Border-Patterns für Interop mit MPLS/SR-MPLS etablieren.
- Phase 4: Schrittweise Service-Migration, beginnend mit klar abgegrenzten Use-Cases.
- Phase 5: Skalierung und Standardisierung, Micro-SIDs oder Overhead-Optimierungen dort einsetzen, wo sie messbar helfen.
Koexistenz ist normal, Variantenexplosion nicht
In der Übergangszeit koexistieren Technologien. Das ist akzeptabel, solange die Anzahl der Varianten begrenzt bleibt: wenige Blueprint-Patterns, klare Domänengrenzen, konsistente MTU- und Telemetry-Profile. Jede zusätzliche Sonderlösung erhöht OPEX und erschwert Fehlersuche.
Observability: SRv6-Pfade müssen im Betrieb erklärbar sein
SRv6 bringt zusätzliche Abstraktion. Das ist gut, solange Pfadwahl und Service-Intention transparent bleiben. Eine Telemetry-Strategie sollte deshalb nicht nur Auslastung messen, sondern SRv6-spezifische Sicht liefern: welche Policies aktiv sind, welche Segmentlisten genutzt werden, wie sich Pfade bei Failover ändern und wo Overhead-/MTU-Probleme entstehen.
- Policy- und Pfadtransparenz: Sichtbarkeit, welche Flows welchen SRv6-Policies folgen.
- Performance-KPIs: Latenz, Loss, Jitter pro Pfadklasse und Region, historisiert.
- Overhead/MTU-Indikatoren: Drops, Fragmentierungshinweise, PMTUD-Fehlerbilder.
- Failure-Korrelation: Trassen-/Link-Events als Root Cause, Traffic-Shifts als erwartete Folge.
Evidence-by-Design: Migration und Betrieb auditierbar machen
SRv6 wird deutlich einfacher zu betreiben, wenn Policies versioniert, Changes nachvollziehbar und Failover-Verhalten regelmäßig getestet wird. Damit entstehen Nachweise für SLA und Governance automatisch: Telemetry-Daten, Change-Historie, Testprotokolle und definierte Runbooks.
Praktische Topology Patterns für SRv6 in Telco-Netzen
- SRv6 Core Domain: SRv6 im Backbone, Policies für Low-Latency/High-Capacity/Resilience, klare Border-Gateways.
- Metro Edge SRv6: Regionale Cluster als Ingress/Egress, lokale Service-Edges, SRv6 für Wartung und Hotspot-Steuerung.
- DC/Edge PoP SRv6: SRv6 für Service-Chaining-nahe Pfade, strikte MTU- und Telemetry-Standards.
- Micro-SID Optimized Domain: Einsatz dort, wo SRH-Overhead messbar limitiert (lange Segmentlisten, knappe MTU).
Ein einfaches Entscheidungsmodell: Overhead-Optimierung nur, wenn sie messbar wirkt
Wenn Segmentlisten kurz sind und MTU ausreichend ist, ist Micro-SID-Optimierung oft unnötig. Wenn Segmentlisten länger werden, MTU knapp ist oder Goodput-Ziele kritisch sind, kann Micro-SID einen messbaren Unterschied machen – vorausgesetzt, das Design bleibt standardisiert.
Leitlinien für robustes SRv6 Design in der Praxis
- MTU zuerst definieren: Netzweite MTU-Standards und Failoverpfade prüfen.
- Domänen sauber schneiden: SRv6 als klar definierte Domäne einführen, Border-Patterns für Interop nutzen.
- Policies als Profile: Wenige Pfadklassen statt viele individuelle Policies.
- Overhead messen: Goodput, Drops und Latenz unter Last erfassen, bevor optimiert wird.
- Micro-SIDs gezielt: Dort einsetzen, wo SRH-Overhead real limitiert und Plattformen es konsistent tragen.
- Failure Handling testen: Link/Node/Trasse/Degradation als Standardtests, nicht als Ausnahme.
- Observability als Pflicht: Pfad- und Policy-Transparenz plus Overhead-/MTU-Indikatoren.
- Governance durchsetzen: Versionierung, Reviews, Wellen-Rollouts, Ausnahmen streng kontrollieren.
