Underlay/Overlay in Telco-Netzen: SR-MPLS, SRv6, EVPN und SDN

Underlay/Overlay in Telco-Netzen ist ein zentrales Architekturkonzept moderner Provider-Infrastrukturen: Das Underlay bildet die stabile, skalierbare IP-Transportbasis (Routing, Konnektivität, Konvergenz, Kapazität), während das Overlay darauf aufbauend Services abstrahiert und segmentiert (VPNs, L2/L3-Dienste, Multitenancy, Traffic Engineering, Service-Chaining). In der Praxis ist genau diese Trennung ein Schlüssel, um Carrier-Grade Anforderungen wie Verfügbarkeit, schnelle Wiederherstellung, kontrollierte Failure Domains und effiziente Betriebskosten zu erfüllen, ohne dass jedes Service-Feature den Transportkern unnötig kompliziert. Technologien wie SR-MPLS und SRv6 ermöglichen im Underlay eine moderne, policy-basierte Pfadsteuerung, EVPN dient im Overlay als skalierbares Control-Plane-Modell für Layer-2- und Layer-3-Services, und SDN liefert die übergeordnete Orchestrierung sowie Automatisierung. Dieser Artikel erklärt verständlich, wie Underlay und Overlay in Telco-Netzen zusammenspielen, welche Rollen SR-MPLS, SRv6, EVPN und SDN jeweils einnehmen und wie Sie eine Architektur entwerfen, die stabil bleibt, mitwächst und im Betrieb beherrschbar ist.

Grundprinzip Underlay vs. Overlay: Stabilität unten, Service-Logik oben

Das Underlay ist die „physische und logische Transportstraße“: IP-Adressierung, IGP-Domänen, Link-Kapazität, Konvergenzverhalten und die eigentliche Weiterleitung sind hier verankert. Das Overlay ist die „Serviceebene“: Es definiert Kundensegmente, VPNs, virtuelle Netze, Broadcast-Domänen (falls nötig), Richtlinien und oft auch Traffic Engineering aus Service-Sicht. Die Trennung bringt zwei entscheidende Vorteile: Erstens bleibt der Transportkern einfacher und stabiler. Zweitens lassen sich Services schneller einführen und verändern, ohne jedes Mal in den Kern einzugreifen.

• Underlay: IP-Transport, Konvergenz, ECMP, Kapazität, Failure-Domains, Pfadoptionen.
• Overlay: L2/L3-Services, VPNs, Multitenancy, Service-Isolation, Policy-Abstraktion.
• Gemeinsames Ziel: Skalierbarkeit und Resilienz, ohne Komplexitäts-Explosion im Betrieb.

Warum Telcos besonders von der Trennung profitieren

Telco-Netze tragen viele Serviceklassen parallel: Internetzugang, Mobilfunktransport, Business-VPNs, Wholesale, Cloud-Onramps, Edge-Services. Wenn jede Serviceinnovation Änderungen im Underlay erzwingt, steigt das Risiko für großflächige Incidents. Ein sauberes Underlay/Overlay-Modell ermöglicht dagegen, Services in der Overlay-Schicht zu entwickeln, während das Underlay „nur“ die definierte Transportqualität bereitstellt.

Das Underlay in Telco-Netzen: Anforderungen und Designziele

Ein gutes Underlay ist boring im besten Sinne: vorhersehbar, stabil, standardisiert. Es liefert Konnektivität und Pfadoptionen, ohne dass sich Service-spezifische Sonderlogik in den Kern frisst. Für Telcos sind dabei typische Ziele: schnelle Wiederherstellung bei Link- und Knotenfehlern, echte physische Diversität, planbare Latenz und ein Kapazitätsmodell, das Störfallreserve berücksichtigt.

• Stabile Konvergenz: Schnelle Erkennung und Umschaltung bei Link/Node-Ausfällen.
• Begrenzte Failure Domains: Regionale Domänen statt „alles hängt an allem“.
• Kapazität & Reserve: Störfallfähigkeit einplanen, nicht nur Normalbetrieb.
• Operationalisierung: Telemetry, klare Rollenmodelle, standardisierte Templates.

Underlay-Topologien: Hierarchie, Metro-Cluster und partielles Mesh

Im Provider-Umfeld ist das Underlay oft hierarchisch strukturiert: Access sammelt, Metro aggregiert, Core verbindet Regionen. In Ballungsräumen bewähren sich Metro-Cluster, die Access dual-homed aufnehmen und redundant in den Core führen. Im Backbone ist ein partielles Mesh üblich, um mehrere unabhängige Pfade zwischen strategischen PoPs bereitzustellen, ohne Vollmesh-Kosten und -Komplexität.

Segment Routing im Underlay: SR-MPLS und SRv6 im Überblick

Segment Routing (SR) erweitert das Underlay um moderne, policy-basierte Verkehrslenkung. Statt Pfade ausschließlich über klassische Metriken und Hop-by-Hop-Entscheidungen zu beeinflussen, können gewünschte Pfade durch eine Sequenz von Segmenten beschrieben werden. Das macht Traffic Engineering flexibler und kann betriebliche Komplexität reduzieren, wenn es sauber standardisiert und automatisiert ausgerollt wird.

SR-MPLS: Segment Routing auf MPLS-Basis

SR-MPLS nutzt MPLS-Labels als Segmente. In vielen Telco-Umgebungen ist MPLS historisch etabliert, etwa für VPN-Dienste, Traffic Engineering und Service-Segmentierung. SR-MPLS kann deshalb eine evolutionäre Weiterentwicklung sein: Das Underlay bleibt MPLS-fähig, während SR-Mechanismen für Pfadsteuerung und Policy durchgesetzt werden.

• Stärken: Oft gut integrierbar in bestehende MPLS-Servicewelten, bewährte Betriebsmodelle.
• Typische Use Cases: Traffic Engineering, L3VPN-Transport, kontrollierte Pfadwahl für kritische Services.
• Wichtig: Konsistente Policies und klare Domänenbildung, damit Pfadsteuerung nachvollziehbar bleibt.

SRv6: Segment Routing über IPv6

SRv6 transportiert Segment-Informationen in IPv6-Konzepten und ermöglicht damit eine sehr flexible Service- und Pfadmodellierung. Für Telcos ist SRv6 besonders interessant, wenn IPv6 ohnehin strategisch ausgebaut wird oder wenn man langfristig ein konsolidiertes, IP-zentriertes Transport- und Servicekonzept anstrebt. Gleichzeitig ist SRv6 in der Praxis stark von Plattformfähigkeiten, MTU-Design und Betriebsreife abhängig.

• Stärken: Hohe Flexibilität, gute Basis für Service-Chaining und moderne Service-Modelle.
• Typische Use Cases: Advanced Traffic Engineering, Service-Encapsulation, Edge- und Cloud-nahe Architekturen.
• Wichtig: MTU-Planung, Telemetry, konsistente Implementierung und klare Migrationspfade.

EVPN als Overlay-Control-Plane: Skalierbare Services für L2 und L3

EVPN (Ethernet VPN) ist ein Control-Plane-Konzept, das häufig als Overlay für skalierbare Layer-2- und Layer-3-Services genutzt wird. In Telco-Netzen spielt EVPN vor allem dort eine Rolle, wo viele Kunden, Standorte oder virtuelle Netze effizient segmentiert werden müssen: Metro-Ethernet, Business-Services, Data-Center-Interconnect, Edge-Services und Multitenancy-Umgebungen.

• Service-Skalierung: Viele VPN-Instanzen mit klarer Trennung und standardisierten Policies.
• Operationalisierung: Reduktion unnötiger Flooding-Domänen, bessere Steuerbarkeit.
• Flexibilität: Unterstützung verschiedener Servicearten (L2 und L3) in einem konsistenten Modell.

EVPN in Telco-Realität: Wo es besonders sinnvoll ist

EVPN ist besonders stark in Bereichen, in denen L2-Dienste noch relevant sind oder wo eine serviceorientierte, mandantenfähige Architektur benötigt wird. Beispiele sind Business-Ethernet-Services, Wholesale-Angebote, Aggregation von Zugangsnetzen oder Edge-PoPs mit mehreren Service-Instanzen. Wichtig ist, die L2-Domänen bewusst zu begrenzen, damit Failure Domains und Broadcast-Last nicht unkontrolliert wachsen.

Overlay-Mechanik: Tunnels, Encapsulation und Service-Abstraktion

Ein Overlay benötigt eine Transportkapselung, um Service-Traffic über das Underlay zu bewegen. In Telco-Netzen ist der entscheidende Punkt weniger die reine Kapselung, sondern das Zusammenspiel: Das Underlay muss Pfadoptionen und Qualität liefern, während das Overlay Service-Isolation, Adressierung, Policy und ggf. L2-Semantik bereitstellt. Je klarer diese Zuständigkeiten getrennt sind, desto leichter lässt sich die Architektur betreiben.

• Underlay liefert: Konnektivität, Pfadvielfalt, Konvergenz, Kapazität, physische Diversität.
• Overlay liefert: Service-Instanzen, Mandantenfähigkeit, L2/L3-Abstraktion, Policy-Kontrolle.
• Gemeinsame Leitlinie: Transport bleibt generisch, Services bleiben modular.

Die häufigste Fehlerquelle: Service-Logik in den Kern ziehen

Wenn Service-spezifische Sonderregeln in das Underlay wandern, steigt die Komplexität stark an: mehr Ausnahmefälle, mehr Fehlkonfigurationsrisiken, schwerere Fehleranalyse. Besser ist ein Rollenmodell: Underlay ist standardisiert und minimal, Overlay ist flexibel, aber ebenfalls standardisiert über Templates und Policies.

SDN in Telco-Netzen: Steuerung, Orchestrierung und Guardrails

SDN (Software-Defined Networking) ist im Telco-Kontext weniger „ein Protokoll“ als ein Betriebs- und Steuerungskonzept: Zentralisierte oder logisch zentralisierte Systeme definieren gewünschte Policies, Pfade und Service-Instanzen, die dann automatisiert ins Netz ausgerollt werden. SDN ergänzt Underlay/Overlay, indem es Komplexität nicht im Kopf einzelner Spezialisten, sondern in standardisierten Modellen, Templates und Validierungsprozessen abbildet.

• Policy-Orchestrierung: Einheitliche Regeln statt regionaler Sonderlösungen.
• Automatisierung: Schnelleres Provisioning, weniger manuelle Fehler, reproduzierbare Changes.
• Telemetry-Integration: Closed-Loop-Ansätze für Kapazität, Pfadoptimierung und Incident-Reaktion.
• Governance: Versionierung, Rollout-Wellen, Pre-Checks und Rollbacks.

SDN ohne Risiko: Begrenzter Blast Radius durch Wellen-Rollouts

Automatisierung kann OPEX senken, wird aber selbst zur Failure Domain, wenn sie unkontrolliert agiert. In Carrier-Grade Umgebungen bewähren sich Guardrails: Changes in Wellen, klare Abnahmeprüfungen, Rollback-Mechanismen und Limits, wie viele Knoten oder Regionen in einem Schritt betroffen sein dürfen. So bleiben Underlay und Overlay stabil, auch wenn SDN die Geschwindigkeit erhöht.

Architektur-Blueprint: Wie Underlay und Overlay in der Telco-Praxis zusammenspielen

Ein hilfreicher Ansatz ist, eine Referenzarchitektur als Blueprint zu definieren: Core und Metro bilden ein SR-fähiges Underlay mit klaren Domänen und ausreichend Pfadvielfalt. Darauf laufen Overlays für Services: EVPN für L2/L3-Instanzen, zusätzliche Servicefunktionen für VPNs oder Edge-Dienste. SDN setzt Policies durch, überwacht Telemetry und sorgt für konsistente Rollouts.

• Core: Hochkapazitives Underlay, partielles Mesh, SR-Policies für kritische Pfade und Wartungen.
• Metro: Cluster-Strukturen, dual-homed Access, regionale Service-Edges, klare Failure Domains.
• Access: Standardisierte Templates, begrenzte Ringgrößen oder Dual-Homing, klare Übergänge zur Metro.
• Overlay: EVPN-Instanzen für Kunden- und Service-Segmentierung, konsistente Policy-Modelle.
• SDN: Provisionierung, Validierung, Rollout-Steuerung, Telemetry-basierte Optimierung.

Einfaches Denkmodell für Service-Isolation

Service-Isolation ist in Telco-Netzen häufig die zentrale Anforderung. Ein minimales Modell ist: Underlay stellt „Transport“, Overlay stellt „Isolation“. In vereinfachter Logik kann man das als Beziehung formulieren:

$\mathrm{Transport}=\mathrm{Underlay},\mathrm{Isolation}=\mathrm{Overlay}$

In der Praxis bedeutet das: Das Underlay sollte möglichst wenige service-spezifische Ausnahmen enthalten, während das Overlay über standardisierte Instanzen (z. B. EVPN) und Policies die Mandantenfähigkeit sicherstellt.

Migrationsstrategien: Schrittweise Einführung ohne Big Bang

Viele Telcos betreiben heterogene Netze mit historisch gewachsenen Technologien. Eine erfolgreiche Migration respektiert bestehende Services und führt neue Konzepte schrittweise ein. Häufig beginnt man im Core, weil dort die Anzahl der Knoten kleiner ist und der Nutzen von SR-basiertem Traffic Engineering hoch ist. Danach folgen Metro-Cluster und schließlich standardisierte Access-Bereiche.

• Schrittweise Domänen: Neue SR-fähige Bereiche zunächst als eigene Domäne etablieren und sauber anbinden.
• Koexistenz planen: Übergänge zwischen Legacy und neuen Bereichen definieren, Monitoring vereinheitlichen.
• Service zuerst stabil: EVPN/Overlay-Dienste in Pilotregionen einführen, dann skaliert ausrollen.
• SDN mit Guardrails: Automatisierung erst mit Validierung, Wellen-Rollouts und Rollbacks produktiv machen.

Die häufigsten Migrationsfallen

• Unklare MTU-Planung: Encapsulation und SR-Mechanismen müssen im gesamten Pfad berücksichtigt werden.
• Zu viele Varianten: Ohne Blueprints explodiert die Anzahl an Sonderfällen und Policies.
• Fehlende Telemetry: Wenn Pfade nicht sichtbar sind, wird Troubleshooting langsamer und teurer.
• Shared Risk ignoriert: Logische Redundanz ohne physische Diversität bleibt Scheinsicherheit.

Betrieb und OPEX: Wie Underlay/Overlay Komplexität beherrschbar macht

Underlay/Overlay ist auch ein OPEX-Modell. Wenn das Underlay stabil, standardisiert und gut beobachtbar ist, sinken die Betriebskosten: weniger Routing-Instabilität, weniger großflächige Incidents, schnellere Fehlereingrenzung. Overlays wie EVPN reduzieren Flooding-Last und vereinheitlichen Service-Control-Plane-Mechanismen. SDN wiederum kann Provisionierung und Compliance automatisieren. Der Effekt ist besonders stark, wenn Blueprints existieren und jede Region nach denselben Mustern aufgebaut ist.

• Weniger manuelle Arbeit: Templates und SDN reduzieren Handarbeit und Fehlkonfigurationen.
• Schnellere Entstörung: Failure Domains und Pfadlogik sind bekannt und sichtbar.
• Bessere Skalierung: Neue Services entstehen im Overlay, ohne den Transportkern zu destabilisieren.
• Planbare Wartung: SR-Policies können Wartungspfade unterstützen und Risiko reduzieren.

Monitoring als Pflichtbestandteil

Je stärker Services abstrahiert und Pfade gesteuert werden, desto wichtiger wird Sichtbarkeit: Pfadtransparenz, Auslastung, Latenz, Jitter und Paketverlust müssen pro Domäne und Serviceklasse messbar sein. Nur so bleibt die Architektur carrier-grade – nicht nur im Design, sondern im echten Betrieb.