Network Design & Topology im Telekommunikationsnetz: Referenzframework für Experten

Ein Network Design & Topology im Telekommunikationsnetz lässt sich nicht sinnvoll „aus dem Bauch heraus“ planen. Carrier-Grade Netze sind groß, stark redundant, multi-vendor, servicegetrieben und stehen unter permanentem Change-Druck: Ausbauwellen, neue Peering-Partner, SR/EVPN-Migrationen, DDoS-Events, IPv4-Knappheit, Rolling Upgrades. Wer hier nur einzelne Technologien bewertet, übersieht die entscheidende Ebene: die Topologie als Systemrahmen aus Failure Domains, Pfadmodellen, Kapazitätslogik und Betriebsprozessen. Ein Referenzframework für Experten schafft Ordnung, indem es Designentscheidungen in wiederholbare Schritte übersetzt: Anforderungen → Domänenschnitt → Topologiepattern → Routing-/Policy-Modelle → Schutz-/Konvergenzkonzept → Service-Blueprints → Observability & Ops → Evidence-by-Design. Dabei geht es nicht darum, ein „einzig richtiges“ Telco-Design zu liefern, sondern eine strukturierte Methodik, mit der Sie unterschiedliche Netze (Core, Metro, Access, Internet Edge, DCI, Mobile Backhaul, FTTH) konsistent planen, prüfen und betreiben können. Dieses Framework ist bewusst praxisnah: Es definiert Rollen, Kanten, Guardrails und messbare Design-KPIs (Konvergenz, Availability, Cost/Bit, Operational Complexity), sodass Architekturentscheidungen auditierbar werden und Outages systematisch vermieden werden. Der Fokus liegt auf einer Expertenperspektive: nicht nur „wie“, sondern „warum“, „wo die Fallen liegen“ und „wie man Designqualität nachweist“.

Framework-Übersicht: Von Anforderungen zu überprüfbaren Designentscheidungen

Ein Telco-Referenzframework muss zwei Spannungen auflösen: Einerseits benötigen Carrier-Designs Standardisierung (Blueprints, Templates, klare Regeln), andererseits sind reale Netze heterogen (Städte vs. Land, Glas vs. Funk, Retail vs. Enterprise, verschiedene Plattformen). Das Framework arbeitet deshalb mit Domänen, Rollen und Gates: Jede Domäne (z. B. Core, Metro, Internet Edge) bekommt ein Standardpattern und klare Grenzen; jede Entscheidung wird über KPIs und Nachweise (Evidence) verifiziert.

• Domänenmodell: Core Backbone, Metro/Aggregation, Access, Internet Edge/Interconnect, DCI/Cloud, Service Edges, Management/Observability.
• Rollenmodell: P/Transport, PE/Service Edge, RR/Control Plane, Aggregation/Hub, Security/DDoS, Management/Telemetry.
• Gate-Modell: Review-Gates mit Stop/Go-Kriterien (SRLG, Headroom N-1, Max-Prefix, MTU, QoS, FRR Coverage).
• KPI-Modell: Konvergenz, Availability, Cost/Bit, Operational Complexity als Designziele und Kontrollgrößen.

Leitprinzip: Design ist nur gut, wenn es verifizierbar ist

Ein Diagramm ist kein Nachweis. Ein Framework verlangt messbare Kriterien und Tests (Lab, Intent Validation, Failure Workshops, Canary), damit Entscheidungen reproduzierbar und auditierbar sind.

Schritt 1: Anforderungen präzisieren und priorisieren

Telco-Design beginnt mit Anforderungen, aber nicht in Form von „wir brauchen SR“ oder „wir wollen EVPN“, sondern als Service- und Betriebsziele. Experten arbeiten mit Zielwerten und Lastfällen: Normalbetrieb, N-1 (Wartung), N-2 (kritische Absicherung), DDoS-/Peak-Events, Region-Failover. Außerdem werden Anforderungen nach Serviceklassen gewichtet (Retail/Wholesale/Enterprise/Mobile), weil nicht jede Klasse dieselben SLOs benötigt.

• Servicekatalog: Internet, L3VPN/L2VPN, Wholesale Bitstream, Mobile Backhaul, FTTH, Anycast-Dienste, DDoS-Schutz.
• SLOs: Availability, p95/p99 Latenz, Loss/Jitter (wo relevant), Recovery-Ziele nach Failure-Klasse.
• Skalierung: Ports/Links, Sites, Sessions (BNG/CGNAT), Prefixe/Routes, VRFs/EVPN Instances, Policies.
• Constraints: Budget, Zeit, vorhandene Fiber/Trassen, Facility-Limits, Vendor-Strategie, Compliance/Logging.

Anti-Pattern: Anforderungen ohne „Degraded Mode“

Carrier-Grade Netze laufen regelmäßig im N-1. Wenn SLOs und Verhalten im Degraded Mode nicht definiert sind, entsteht bei Wartung oder Ausfällen unkontrollierte Degradation.

Schritt 2: Domänenschnitt und Failure Domains definieren

Domänenschnitt ist das Fundament für Resilienz und Operability. Ein Design ohne klare Failure Domains ist schwer zu warten und kann lokale Probleme global eskalieren lassen. Experten definieren Domänen nach Topologie und Wirkung: PoP, Region, Ring, DCI-Fabric, Internet Edge, Management-Domäne. Zusätzlich werden SRLGs (Trassen/Fiber-Bundles/Facilities) explizit erfasst, weil physische Nicht-Diversität die häufigste Ursache für „Redundanzversagen“ ist.

• Failure Domains: PoP/Region/Ring/DCI/Edge als klare Container, inklusive erwarteter Blast Radius.
• Maintenance Domains: Upgrade-Wellen so schneiden, dass nie beide Redundanzseiten gleichzeitig betroffen sind.
• SRLG-Disziplin: Redundanz gilt nur, wenn Pfade physisch divers sind (Trasse, MMR, Power).
• Containment: Spezialfunktionen (DDoS, CGNAT, BNG, Firewall) in eigenen Domänen kapseln.

Designregel: „Planned Failure“ ist ein Designinput

Wartung ist planbar, deshalb muss sie topologisch möglich sein: Drain-Mechanismen, duale Kanten und klare Domänengrenzen gehören ins Framework.

Schritt 3: Topologiepattern auswählen und skalierbar machen

Topologiepattern sind die wiederverwendbaren Bausteine: Ring, Mesh, Hub-and-Spoke, Spine-Leaf (DC), Dual-Core/Multi-Core, Dual-Hub Aggregation. Experten wählen Pattern nicht nach Geschmack, sondern nach KPI-Gewichtung und operativer Reife. Ringe sind klar und gut schützbar, Mesh optimiert Auslastung, Hub-and-Spoke vereinfacht – erhöht aber Hub-Kritikalität. Das Framework fordert außerdem „Growth Rules“: ab wann wird ein Ring gesplittet, ab wann wird ein Mesh ergänzt, ab wann braucht man zusätzliche Hubs?

• Core Backbone: Dual-Core pro Region, partial mesh zwischen Regionen, klare Linkklassen (Core, DCI, Edge).
• Metro/Aggregation: Metro Ring oder Dual-Hub Aggregation als Standard; Mesh nur mit Observability und TE-Disziplin.
• Access: Dual-Homing wichtiger Standorte, L2 klein halten, L3 als Skalierungsgrenze.
• Internet Edge: Multi-Edge pro PoP, diverse IXPs/Transits, policy-rich Edge, transport-boring Core.

Anti-Pattern: Pattern ohne Skalierungsgrenzen

Ohne definierte Grenzen wird ein Ring „immer größer“ oder ein Mesh „immer dichter“, bis Control Plane, Headroom oder Operability kippen. Growth Rules sind Pflicht.

Schritt 4: Underlay-Design (IGP) als Stabilitätskern

Das IGP bildet den Transportgraphen ab. Ein gutes Underlay ist konservativ, konsistent und gut beobachtbar. Das Framework verlangt: Hierarchie (Areas/Levels) passend zur Topologie, kontrollierte Flooding-Scopes, sinnvolle Summarization, stabile Timerprofile und Schutz vor Churn. IGP ist nicht der Ort für Business-Policy – dafür gibt es BGP/TE.

• Hierarchie: Regionen als Subdomänen, Backbone als übergeordnete Ebene; klare Grenzen für Summaries.
• Metrikmodell: Linkklassen und Kapazität abbilden, ohne „Policy-Kunststücke“ mit IGP-Kosten.
• Stabilitätsprofile: SPF/Update-Throttling und BFD/Tuning konservativ und getestet.
• Control-Plane Schutz: CoPP und Monitoring für IGP/BFD, um Überlast früh zu erkennen.

Designregel: IGP muss im Wachstum langweilig bleiben

Wenn IGP-Änderungen bei jeder Ausbauwelle notwendig sind, ist die Domänen- oder Summarization-Logik falsch. Das Framework fordert IGP-Design, das Wachstum absorbiert.

Schritt 5: Segment Routing als Transport- und TE-Werkzeug

Segment Routing (SR) ist für viele Telcos das strategische Transportmodell (meist SR-MPLS, optional SRv6). Das Framework trennt SR in zwei Ebenen: SR als Underlay-Funktion (Node-SIDs, SRGB, FRR) und SR-TE/Policies als optionales Steuerwerkzeug. Entscheidend ist Konsistenz: SRGB und SID-Zuweisung sind Vertragsparameter. Und Resilienz muss messbar sein: FRR/TI-LFA Coverage darf keine Vermutung sein.

• SRGB/SIDs: Einheitlicher SRGB-Plan, klare Pools für Node-/Anycast-SIDs, keine vendor-default Drift.
• FRR/TI-LFA: Coverage-Ziele, Failure-Klassen (Link/Node) und Nachweisverfahren (Reports/Tests).
• Policies/TE: Progressive Einführung, Hotspot-Guardrails, QoS/Headroom an Engpässen.
• Interop: „Lowest common denominator“ im Transport, Innovation in abgegrenzten Domänen.

Anti-Pattern: SR-Policies ohne Observability

TE kann Congestion verschieben. Ohne Flow-Visibility und Engpass-KPIs wird Policy-Design blind und erhöht Incident-Risiko.

Schritt 6: BGP-Design als Hierarchie- und Policy-Backbone

BGP ist im Provider-Netz die zentrale Policy-Ebene – intern (iBGP) und extern (eBGP). Das Framework fordert eine klare RR-Hierarchie, Redundanz über Failure Domains, strikte Guardrails gegen Leaks/Loops und eine standardisierte Community-Sprache. Ziel ist, dass Policy-Änderungen kontrollierbar bleiben und Routing-Failures topologisch verhindert werden.

• RR-Topologie: Mindestens zwei RRs pro Client, getrennte Domains, optional hierarchisch (regional + übergeordnet).
• Guardrails: Max-Prefix, Default-deny Export, Export-Whitelists, No-Transit Regeln, Leak-Prevention.
• Community Contract: Einheitliche Communities für LocalPref, blackhole, prepend, region tags, no-export.
• Failure Handling: Partition-Szenarien, Graceful-Mechaniken, Rollback und Canary für RR/Policy-Changes.

Designregel: Policies müssen vorab auf Wirkung geprüft werden

Ein Diff zeigt nicht, welche Routen tatsächlich exportiert werden. Das Framework verlangt Intent Validation: „Policy Output“ als Gate vor jedem Change.

Schritt 7: Service-Blueprints und Topologieabbildung

Carrier-Grade ist servicegetrieben. Ein Framework muss deshalb Service-Blueprints definieren: L3VPN/L2VPN (E-Line/E-LAN/L3VPN), EVPN Multi-Tenant, Internet Edge, CGNAT/BNG, Mobile Backhaul, FTTH. Jeder Blueprint enthält: Rollen, Pfadmodell (Normal/Failover), Isolation (VRFs/Policies), QoS-Klassen, MTU-Vertrag und Monitoring-KPIs.

• VRF-Isolation: Retail/Wholesale/Enterprise getrennt, explizite Leak-Regeln, klare Ownership.
• Service Chains: Stateful Funktionen (Firewall/CGNAT/DPI) mit Symmetrieanforderungen und Steering-Logik.
• Anycast Services: Health-Gates, Withdraw-Strategien, Region-Failover, DDoS-Integration.
• Subscriber Scale: BNG Placement, Session-Sharding, AAA-Resilienz, Churn-Headroom im Failover.

Anti-Pattern: Service ohne Pfadmodell

Wenn Normal- und Failoverpfad nicht explizit sind, kann man weder QoS noch MTU noch Kapazität sauber planen. Das Framework verlangt pro kritischem Service einen Pfad-View.

Schritt 8: QoS-Topologie und MTU als End-to-End Verträge

In Telco-Netzen sind QoS und MTU keine Details, sondern Verträge. Viele Outages sind Degradations durch Drops, Imbalance oder MTU-Blackholes – besonders im Failover. Das Framework verlangt deshalb ein einheitliches Klassenmodell, klare Trust Boundaries und Queueing/Policing an Engpässen. Ebenso verlangt es Mindest-MTUs pro Linkklasse und Failover-Tests.

• QoS Klassenmodell: Wenige robuste Klassen (Realtime, Critical, Best Effort, Bulk, Management), rollenbasiert umgesetzt.
• Engpasskarte: Wo sind Engpässe (Metro-Hubs, DCI, IXPs, Transitlinks)? Dort wird gequeued.
• Degraded Mode: Failover-QoS-Profil, das kritische Klassen schützt und Bulk begrenzt.
• MTU-Plan: Overhead (MPLS/SR/EVPN/QinQ) einkalkulieren, PMTUD/ICMP-Policies, MSS-Strategien.

Designregel: QoS und MTU müssen im Schutzpfad funktionieren

Normalpfad-Optimierung reicht nicht. Das Framework verlangt Tests und KPIs auch für Failoverpfade, DCI-Umlenkung und Scrubbing-Pfade.

Schritt 9: Security Domains, Control-Plane Protection und DDoS-Integration

Security ist topologisch. Ein Expertenframework definiert Segmentierung nach Kunden/Services/Betriebsrollen, Management-Zonen und Control-Plane Protection (CoPP). Zusätzlich wird DDoS-Abwehr als integrierter Baustein geplant: Scrubbing Centers, Anycast, Steering, RTBH/FlowSpec – mit strikten Guardrails (Autorisierung, Scope, Expiry, Containment).

• Security Segmentation: VRFs/Zones für Retail/Wholesale/Enterprise, Management getrennt, klare Allowed Flows.
• CoPP: Rollenbasierte Profile, getestet, mit Monitoring der Matches und Drops.
• DDoS Blueprint: Scrubbing Placement (regional/zentral), Steering-Mechaniken, Mitigation Workflows.
• Guardrails: Autorisierte Quellen, Scope-Control, automatische Ablaufzeiten, Auditability.

Anti-Pattern: DDoS-Mitigation ohne Governance

Die gefährlichsten Fehler sind falsche Mitigations. Das Framework verlangt Autorisierung, begrenzten Scope und Expiry als Pflicht für Mitigation-Mechanismen.

Schritt 10: Observability-by-Design und Operations als First-Class Designziele

Ein Telco-Design ist nur dann carrier-grade, wenn es betrieben werden kann. Observability-by-Design bedeutet: Telemetry-Pfade sind geplant, Sampling ist skaliert, SLO-Messpunkte sind topologisch verteilt, und Alarmierung liefert Signal statt Noise. Ops-by-Design bedeutet: Wartungsdomänen, Canary-Methodik, Stop/Go-Gates, Rollback-Prozeduren und Evidence-by-Design sind Bestandteil des Blueprints.

• Pflichtmetriken: Loss/RTT/Jitter (wo relevant), Queue-Drops, Portauslastung, per-member LAG, CPU/Memory, IGP/BGP Health, FRR-Events.
• Flow Visibility: IPFIX/NetFlow Placement, Sampling-Strategien, Hotspot- und DDoS-Analysefähigkeit.
• High-Signal Alerts: Korrelation (z. B. Link down + FRR + Drops), Runbooks, klare Severity.
• Change Prozess: Canary → Batch → Welle, objektive Gates, getesteter Rollback, Evidence Archive.

Designregel: Ein Design ohne Rollback ist nicht fertig

Rollback ist kein Incident-Plan, sondern ein Designartefakt. Das Framework verlangt reversible Mechanismen und getestete Prozeduren für kritische Changes.

Design KPIs als Steuerinstrument: Konvergenz, Availability, Cost/Bit, Operational Complexity

Ein Expertenframework bewertet Topologie nicht nur qualitativ, sondern KPI-basiert. Dazu werden Zielwerte pro Domäne definiert. Wichtig ist die Koppelung: Konvergenz und Availability hängen an Schutzmechanismen und Headroom, Cost/Bit hängt an Auslastung und Hardware-/Transitkosten, Operational Complexity hängt an Varianten, State und Change-Failure-Rate.

• Konvergenz: Detection + Protection + Stabilisierung + Service-Recovery, getrennt nach Link/Node/Region Events.
• Availability: Serviceorientiert (inkl. Degradation), getrennt nach Domäne und Serviceklasse.
• Cost/Bit: (CAPEX + OPEX) / DeliveredBits, inklusive N-1 Lastfälle und Incident-Kosten.
• Operational Complexity: Change-Failure-Rate, MTTR, Drift, Exceptions, Signal/Noise als Proxy-KPIs.

Ein KPI-Gate als formale Go-Logik

$\mathrm{Go}=(\mathrm{Convergence}\le \mathrm{Target})\wedge (\mathrm{Availability}\ge \mathrm{Target})\wedge (\mathrm{CostPerBit}\le \mathrm{Budget})\wedge (\mathrm{OpsComplexity}\le \mathrm{Threshold})$

Evidence-by-Design: Wie Experten Designqualität nachweisen

Carrier-Grade Frameworks fordern Evidence: nicht nur „wir glauben“, sondern „wir haben geprüft“. Evidence entsteht aus Lab-Reproduktion (Containerlab/EVE-NG), Simulationen, Intent Validation, Failure Scenario Workshops und Canary-Rollouts. Besonders wichtig: Expected vs. Observed dokumentieren, damit spätere Änderungen nicht auf Annahmen basieren.

• Failure Workshops: Link-, Node-, Region-Ausfälle durchspielen, Blast Radius und Recovery messen.
• Intent Validation: Guardrails prüfen (Leaks, Max-Prefix, MTU-Minimum, QoS-Profil, CoPP aktiv).
• Lab-Reproduktion: Kritische Protokoll- und Servicepfade nachbauen, Failover testen, Coverage nachweisen.
• Canary: Progressive Rollouts mit Stop/Go-Gates und Rollback, bevor Wellen skaliert werden.

Anti-Pattern: „Wir testen im Produktivnetz“

Produktivtests sind wichtig, aber als Canary, nicht als erster Nachweis. Das Framework verlangt Pre-Validation, damit der Canary kein Glücksspiel ist.

Praktische Leitlinien: Das Referenzframework in Blueprints und Prozesse übersetzen

• Blueprints pro Domäne: Core Backbone, Metro Ring, Internet Edge, FTTH Access, Mobile Backhaul, DCI – jeweils mit Rollen, Kanten, Guardrails.
• Layer-Docs standardisieren: L1/L2/L3/Services/Ops getrennt, verknüpft über stabile IDs und Source of Truth.
• Review-Gates verpflichtend machen: SRLG-Diversität, Failure Domains, N-1 Headroom, Max-Prefix/Export-Whitelist, MTU/QoS, FRR Coverage.
• KPI-Ziele definieren: Konvergenz/Availability/Cost/Bit/Ops-Complexity pro Domäne und Serviceklasse gewichten.
• Observability-by-Design: Pflichtmetriken, Flow-Visibility, SLO-Messpunkte, High-Signal Alerts als Bestandteil jedes Blueprints.
• Change als Release: Canary → Batch → Welle, Stop/Go-Gates, getesteter Rollback, Evidence Archive.
• Governance für Ausnahmen: Sonderfälle nur mit Review, Audit und Ablaufdatum, sonst wächst Komplexität dauerhaft.
• Lessons Learned einbauen: Outage-Muster in Gate-Kriterien und Standards überführen, statt ad hoc zu patchen.