Telco Blueprint “FTTH Access”: Aggregation, BNG Placement und Scale

Ein Telco Blueprint „FTTH Access“ beschreibt das Referenzdesign für Glasfaser-Zugangsnetze – vom OLT/Access über die Aggregation bis hin zum BNG/BRAS Placement und der Skalierung von Subscriber-Sessions. FTTH ist technisch attraktiv, weil die physische Infrastruktur langfristig leistungsfähig ist. Operativ wird FTTH jedoch erst dann „carrier-grade“, wenn die Netzarchitektur saubere Failure Domains, klare L2/L3-Grenzen, belastbare Kapazitätsmodelle und standardisierte Betriebsprozesse liefert. Viele Probleme in FTTH-Programmen entstehen nicht auf der Glasfaser, sondern im Aggregations- und Service-Edge-Bereich: zu große L2-Domänen, inkonsistente VLAN/QinQ-Modelle, BNG-Cluster an falscher Stelle, unzureichende Logging- und Telemetry-Pfade oder unklare Session- und Policy-Skalierung. Ein professioneller Blueprint beantwortet deshalb explizit: Wo endet Access, wo beginnt Aggregation? Welche Topologie ist im Metro sinnvoll (Ring, Hub-and-Spoke, Partial Mesh)? Wie wird die Übergabe an den BNG gestaltet (L2-Handover vs. L3-Handover)? Welche Redundanzmuster gelten (Dual-Homing, SRLG-Diversität, Maintenance Domains)? Und wie werden Scale-Themen (PPPoe/DHCP, IPv6-PD, CGNAT-Optionen, Policy- und AAA-Integration) topologisch beherrscht? Dieser Artikel liefert ein praxistaugliches Referenzdesign für FTTH Access inkl. Aggregation, BNG Placement und Scale – inklusive Schutzkonzepten, Ops-Bausteinen und messbaren Erfolgsmetriken, damit Wachstum nicht zu Betriebschaos wird.

Zielsetzung des FTTH-Access-Blueprints

Ein FTTH-Blueprint soll Wiederverwendbarkeit schaffen: gleiche Rollen, gleiche Schnittstellen, gleiche Parameter und gleiche Betriebsmechanik – unabhängig davon, ob Sie ein Stadtgebiet ausbauen oder ländliche Regionen erschließen. Gleichzeitig muss er produkt- und servicefähig sein: Retail-Internet, Wholesale-Bitstream, Business-Services, optional IPTV/Multicast und perspektivisch IPv6-first. Das Ziel ist ein Access-Design, das skalierbar bleibt, ohne dass jede neue Ausbauwelle eine neue Sonderarchitektur erzwingt.

• Skalierung: Viele OLTs, viele ONTs, viele Tausend bis Millionen Sessions – ohne Kontrollplan- und OPEX-Explosion.
• Resilienz: Lokale Störungen begrenzen, Dual-Homing dort, wo es wirtschaftlich sinnvoll ist, klare Wartungsdomänen.
• Servicekonsistenz: Einheitliche Policies (QoS, IPv6, Sicherheit), reproduzierbare Provisioningprozesse.
• Operability: Schnelle Fehlereingrenzung (L1/L2/L3/Service), automatisierte Validierung, planbare Upgrades.

Leitprinzip: Access ist Masse – daher müssen Standards strikt sein

FTTH ist ein Skalierungsproblem. Jeder Sonderfall multipliziert sich mit der Zahl der Anschlüsse. Ein Blueprint sollte Sonderfälle minimieren und über klare Produktprofile kapseln.

Referenzrollen und Layer-Grenzen: OLT, Aggregation und Service Edge

Ein FTTH-Netz besteht aus mehreren klaren Rollen. Der Blueprint muss diese Rollen definieren und festlegen, wo die Grenze zwischen L2 und L3 liegt. Die größte Stabilitätssteigerung erzielen Sie, wenn Sie L2-Domänen begrenzen und L3 als Skalierungs- und Failure-Domain-Grenze nutzen.

• OLT/Access (Access Layer): Terminierung der PONs, VLAN/QinQ-Tagging, Service-Port-Modelle, ggf. Multicast-Funktionen.
• Aggregation (Metro/Aggregation Layer): Sammeln vieler OLT-Uplinks, Redundanz (Ringe oder Dual-Hub), QoS-Engpässe, L2/L3-Übergabe.
• BNG/BRAS (Service Edge): Subscriber Management, AAA, Policies, IPv6 Prefix Delegation, ggf. CGNAT-Steering, Accounting.
• Core/Backbone: Reiner Transport (SR/IGP/BGP), keine subscriber-spezifische Komplexität.

Designregel: Jede Funktion hat einen „Home Layer“

VLAN/QinQ ist Access/Aggregation, Session-State gehört zum BNG, Transport gehört in den Core. Wenn diese Verantwortlichkeiten vermischt werden, steigen Drift und Fehlerrisiko.

Access-Topologie: PON-Design, Uplinks und Dual-Homing-Optionen

Im Access selbst sind viele Entscheidungen physisch bedingt (PON-Splits, OLT-Standorte). Dennoch hat Topologie großen Einfluss auf Resilienz und Betrieb: Dual-Uplinks pro OLT, Dual-Homing an zwei Aggregationsknoten, und SRLG-Diversität bei Trassen. Nicht jeder Anschluss braucht maximale Redundanz, aber der Blueprint muss definieren, welche Produktklasse welche Redundanz bekommt.

• OLT-Uplink Standard: Mindestens zwei Uplinks pro OLT (LAG oder getrennte Links), idealerweise zu unterschiedlichen Aggregationsknoten.
• Dual-Homing: OLT an AGG-A und AGG-B (diverse Paths), besonders für Business/Wholesale und zentrale OLT-Hubs.
• SRLG-Disziplin: Redundante Pfade dürfen nicht dieselbe Trasse/Fiber-Bundle teilen, sonst ist Redundanz nur scheinbar.
• Produktprofile: Retail kann andere Resilienzanforderungen haben als Enterprise/Wholesale; Blueprint muss das abbilden.

Anti-Pattern: Redundanz nur logisch, nicht physisch

Wenn beide Uplinks über denselben Schacht laufen, ist ein Baggerereignis ein Totalausfall. SRLG-Tracking und Port-to-Port Dokumentation sind Pflicht.

Aggregation-Blueprint: Ring, Hub-and-Spoke oder Partial Mesh?

Die Aggregation ist der Bereich, in dem FTTH-Scale und Metro-Topologie zusammenkommen. Häufige Patterns sind Metro-Ringe (einfach, klare Protection), Hub-and-Spoke (klar, aber Hub kritisch) oder Partial Mesh (bessere Lastverteilung, mehr Komplexität). Der Blueprint sollte ein Standardpattern definieren und klare Grenzen setzen, wann ein Ring gesplittet oder in Mesh-Elemente erweitert werden muss.

• Metro Ring: Bewährt für Aggregation, klare Failure Domain, gut planbare Protection; erfordert saubere Ring-Protection/Ops.
• Hub-and-Spoke: Einfach, aber Hubs müssen redundant und kapazitätsstark sein; Risiko von Hub-Engpässen.
• Partial Mesh: Querverbindungen zur Engpassentlastung; benötigt gutes ECMP/Traffic Engineering und Observability.
• Dual-Hub Übergabe: Aggregation sollte idealerweise an zwei Hubs (AGG->HUB-A/HUB-B) übergeben, um Wartung zu erleichtern.

Designregel: Aggregation ist eine definierte Maintenance Domain

Upgrades müssen in Wellen erfolgen, ohne beide Redundanzseiten gleichzeitig zu beeinträchtigen. Das muss topologisch möglich sein und im Blueprint festgelegt werden.

L2-Handover vs. L3-Handover: Wo liegt die sinnvolle Grenze?

Eine Kernentscheidung im FTTH-Blueprint lautet: Wird der Subscriber-Traffic als L2 bis zum BNG transportiert (L2-Handover) oder wird früher geroutet (L3-Handover), z. B. in der Aggregation? L2-Handover ist häufig, weil viele Accessmodelle VLAN/QinQ-basiert sind und Wholesale-Bitstream gut abbildbar ist. L3-Handover kann die L2-Failure Domain verkleinern, erfordert aber sorgfältiges VRF- und Policy-Design.

• L2-Handover Vorteile: Einfaches Wholesale-Modell, klare VLAN/QinQ-Trennung, BNG als zentrale Servicekante.
• L2-Handover Risiken: Größere L2-Domänen, potenziell mehr Flooding/Loop-Risiko, MTU-Overhead und Troubleshooting-Komplexität.
• L3-Handover Vorteile: Kleinere Broadcast-Domänen, klarere Failure Domains, bessere Skalierung in manchen Szenarien.
• L3-Handover Risiken: Frühe Policy-Komplexität, VRF-Design muss sauber sein, Interop mit Wholesale kann anspruchsvoller werden.

Anti-Pattern: L2 „über alles strecken“

Große L2-Domänen sind im Mass-Access schwer zu betreiben. Wo möglich, sollte der Blueprint die L2-Ausdehnung begrenzen und L3 als Skalierungsgrenze nutzen.

BNG Placement: Zentral, regional oder metro-nah?

BNG/BRAS Placement ist die strategische Entscheidung des FTTH-Blueprints. Zentral platzierte BNGs sind einfacher zu betreiben, können aber zu Hairpinning, längeren Pfaden und größeren Failure Domains führen. Regionale oder metro-nahe BNGs reduzieren Latenz und Backhaul, erhöhen aber Plattform- und Betriebsaufwand (mehr Standorte, mehr Cluster). Ein guter Blueprint bietet klare Kriterien: Kundendichte, Latenzanforderungen, DCI/Backhaul-Kosten, Resilienzvorgaben und Session-Scale.

• Zentraler BNG: Wenige große Cluster, gute Auslastung, einfache Governance; Risiko größerer Impact bei Ausfall, ggf. längere Pfade.
• Regionaler BNG: Bessere Latenz, weniger Backhaul, kleinere Failure Domains; mehr Plattformen, mehr Ops-Aufwand.
• Metro-naher BNG: Sehr gute Performance, schnelle lokale Failoveroptionen; erfordert konsequente Standardisierung und Automatisierung.
• Dual-Region Strategie: BNG-Cluster pro Region plus Cross-Region-Fallback mit klaren Gates, um DCI nicht zu überlasten.

Designregel: BNG ist stateful – daher sind Failure Domains entscheidend

Ein BNG-Ausfall ist nicht nur „Traffic weg“, sondern auch „Sessions churnen“. Placement muss N-1/N-2 und Session-Recovery-Capacity berücksichtigen.

Scale-Blueprint: Subscriber Sessions, AAA, Policies und Tabellenlimits

FTTH-Scale ist vor allem Control-Plane- und State-Scale: Sessions (PPPoE oder IPoE/DHCP), IPv6 Prefix Delegation, RADIUS/AAA, Accounting, Policy-Downloads, QoS-Profile, und oft CGNAT- oder Firewall-Interaktionen. Der Blueprint muss definieren, wie diese Scale-Dimensionen topologisch kapselt werden: Clustergrößen, Sharding nach Region/PoP, Session-Affinität und Failovermechaniken.

• Session-Sharding: Verteilung von Kunden auf BNG-Cluster nach Region/PoP, um Blast Radius zu begrenzen.
• AAA-Resilienz: RADIUS-Design (lokale Caches, redundante Server), Latenzbudgets und Timeout-Profile.
• IPv6-PD Standard: Prefix Delegation pro Anschluss/Haushalt, konsistentes Prefix-Design passend zur Topologie.
• Tabellenlimits: CPU/Memory, Session-Table, Policy-Table, ACL/QoS Ressourcen – als harte Designparameter.

Ein pragmatisches N-1-Scale-Kriterium

$\mathrm{BNG\_Capacity}\ge \mathrm{Peak\_Sessions}/(N–1)+\mathrm{Churn\_Headroom}$

Churn_Headroom steht für die zusätzliche Last durch Reconnects und Policy/AAA-Aktivität im Failover, nicht nur für „mehr Sessions“.

IPv4/IPv6 im FTTH-Blueprint: Dual Stack, IPv6-first und CGNAT-Optionen

FTTH-Rollouts treffen direkt auf IPv4-Knappheit. Der Blueprint sollte deshalb IPv6 als Standard verankern und IPv4 als kontrollierten Dienst behandeln (Dual Stack, ggf. CGNAT für Mass-Market, public IPv4 als Option). Wichtig ist, dass diese Entscheidungen topologisch sauber umgesetzt werden: wo wird NAT platziert, wie werden Logs geführt, und wie bleibt der Betrieb beherrschbar?

• IPv6-first Prinzip: IPv6 PD standardmäßig, IPv4 als Zusatzdienst je Produktprofil.
• Dual Stack im Übergang: Für Kompatibilität, aber mit gleichen Security- und Monitoringstandards für IPv6.
• CGNAT (optional): Als separate Service-Edge-Domain, nicht im Core; Logging und Capacity als Pflicht.
• Produktsegmentierung: Public IPv4 für Business/Premium, CGNAT für Retail, klare Kommunikation der Einschränkungen.

Anti-Pattern: IPv6 ohne Security-Parität

Wenn ACLs, Firewalls, DDoS-Schutz oder Monitoring nur IPv4 sauber abdecken, entsteht bei IPv6 eine Schattenwelt. Der Blueprint sollte Gleichwertigkeit erzwingen.

Protection- und Resilienzkonzept: Dual-Homing, diverse Paths und Maintenance Mode

FTTH-Access ist häufig „mass market“, dennoch sind Ausfälle teuer. Der Blueprint muss daher definieren, wo Redundanz verpflichtend ist (BNG-Cluster, Aggregationshubs, zentrale OLT-Standorte) und wo „best effort“ ausreicht. Zusätzlich braucht es einen Maintenance Mode: planbare Wartung, die Traffic kontrolliert verschiebt, statt hard abzuschalten.

• OLT Redundanz: Dual-Uplinks, möglichst zu zwei Aggregationsknoten; klare SRLG-Regeln.
• Aggregation Protection: Ring- oder Dual-Hub-Mechaniken, definierte Recovery-Budgets und N-1 Capacity.
• BNG Redundanz: Active/Active oder Active/Standby je Plattform, aber immer mit Session-Churn-Planung.
• Maintenance Mode: Cost-Increase/Drain-Mechaniken, Stop/Go Gates, Rollback.

Designregel: Planned Failure ist ein eigener Lastfall

Während Wartung läuft das Netz im N-1. Der Blueprint sollte definieren, welche SLOs im Degraded Mode gelten und wie QoS/Capacity darauf vorbereitet ist.

QoS-Blueprint: Klassenmodell, Engpässe und Wholesale-Fairness

In FTTH ist QoS nicht nur „nice to have“. Engpässe entstehen an Aggregationslinks, Hub-Uplinks und teilweise im BNG/CGNAT-Pfad. Zusätzlich müssen Wholesale- und Retail-Klassen fair behandelt werden, und Management/Timing-Traffic (NTP/PTP) darf nicht untergehen. Der Blueprint sollte ein einfaches, robustes Klassenmodell definieren und festlegen, wo Marking, Queueing und Policing stattfinden.

• Klassenmodell: Wenige Klassen (Realtime/Critical/Best Effort/Bulk) plus ggf. Management/Control.
• Marking an der Kante: Marking möglichst am BNG/Service Edge oder an definierten Access-Grenzen.
• Queueing an Engpässen: Aggregation/Hubs als primäre Engpässe; dort Drops und Latenz kontrollieren.
• Wholesale Policing: Vertragliche Bandbreiten an Übergaben polizen/shapen, um Overuse zu verhindern.

Anti-Pattern: QoS nur im Core

Wenn QoS erst im Core greift, sind die Drops bereits in der Aggregation passiert. Der Blueprint muss Engpässe topologisch erkennen und dort QoS implementieren.

Ops-Blueprint: Observability, Alarmierung und Runbooks für Mass-Access

FTTH-Operations unterscheiden sich von Backbone-Ops: Sie haben viele gleichartige Elemente (OLTs, Uplinks, Kundenports) und benötigen daher stark standardisierte Telemetry, Labels und High-Signal Alerts. Der Blueprint sollte festlegen, welche Metriken Pflicht sind und wie Incidents entlang der Layer eingegrenzt werden: L1 (Trasse/Circuit), L2 (VLAN/QinQ/LAG), L3 (Routing/Reachability) und Service (Sessions/AAA/Policies).

• Pflichtmetriken Access/Aggregation: Uplink Utilization, Errors, Drops, LAG Member Imbalance, Ring/Protection Events.
• BNG/Service KPIs: Session Count, Session Churn, AAA Latency/Timeouts, Policy Install Rate, CPU/Memory.
• High-Signal Alerts: „OLT-Uplink down + Kundenimpact“ oder „AAA latency spike + session churn“ statt Einzelalarme.
• Runbooks: OLT-Uplink-Ausfall, Aggregationssegment-Ausfall, BNG-Cluster-Degradation, AAA-Störung.

Designregel: Telemetry muss skaliert werden wie das Netz

Mass-Access erzeugt viel Telemetry. Sampling, Batching und Backpressure sind Pflicht, sonst wird Monitoring selbst zur Lastquelle.

Ops-Blueprint: Change-Methodik, Canary-Rollouts und Rollback

FTTH wächst in Wellen (Ausbaugebiete). Genau das kann man operativ nutzen: Jede Ausbauwelle ist ein natürlicher Canary. Der Blueprint sollte progressive Rollouts standardisieren: erst kleine Cluster, dann größere Regionen, mit objektiven Stop/Go-Gates. Rollback muss praktikabel sein: nicht nur Konfig zurück, sondern Traffic- und Session-Steering zurück.

• Canary-Ausbaugebiete: Neue OLTs/BNG-Profiles zuerst in kleinen Bereichen aktivieren, bevor großflächig ausgerollt wird.
• Stop/Go Gates: SLOs (Loss/RTT), Session-Churn, AAA Timeouts, Drops in Aggregation, Ticketvolumen.
• Rollback-Plan: Template-Version zurück, Policy zurück, Drain/Cost-Increase zurücksetzen; getestet im Lab/Pre-Prod.
• Evidence-by-Design: Expected vs. Observed, Reports und Diffs versioniert archivieren.

Anti-Pattern: „Wir schalten ein Gebiet live und schauen“

Ohne Gates und Rollback wird ein lokales Problem schnell zu einem flächigen Incident. Der Blueprint sollte ein standardisiertes Release- und Validierungsverfahren vorschreiben.

Erfolgsmetriken: Woran Sie ein gutes FTTH-Access-Design erkennen

Ein Blueprint ist nur dann wertvoll, wenn Erfolg messbar ist. Für FTTH sollten KPIs sowohl Netz- als auch Serviceebene abdecken: Kapazität, Latenz/Loss, Session-Stabilität, und operative Stabilität (Change-Failure-Rate, MTTR).

• Access/Metro: Headroom an Aggregationslinks, Drops pro Klasse, Fehlerquoten, Ring-/Protection-Event-Rate.
• BNG/AAA: Session-Churn, AAA-Latenz, Timeout-Rate, CPU/Memory, Policy-Install-Fehler.
• IPv6/IPv4: IPv6 Adoption, CGNAT Session/CPS (falls genutzt), Ticketvolumen zu NAT/Portforwarding.
• Operability: MTTR, Change-Failure-Rate, Rollback-Rate, Drift-Events zwischen SoT und Netz.

Praktische Leitlinien: Telco Blueprint „FTTH Access“ für Aggregation, BNG Placement und Scale

• Rollen und Grenzen festlegen: OLT (Access), Aggregation (Metro), BNG (Service Edge), Core (Transport) strikt trennen.
• Aggregation standardisieren: Ring oder Dual-Hub als Standardpattern, klar definierte Failure- und Maintenance-Domänen.
• L2/L3-Grenze bewusst wählen: L2-Handover für Wholesale-Modelle möglich, aber L2-Domänen begrenzen; L3-Handover als Skalierungsoption.
• BNG Placement entscheiden: Zentral vs. regional vs. metro-nah anhand von Kundendichte, Latenzbudgets, Backhaul-Kosten und N-1-Scale.
• Scale als Designparameter: Sessions, CPS, AAA, Policy-Tabellen und Ressourcenlimits in die Topologieplanung integrieren.
• IPv6-first verankern: IPv6 PD als Standard, IPv4 kontrolliert (Dual Stack/CGNAT je Produktprofil), Security-Parität erzwingen.
• QoS an Engpässen: Klassenmodell, Queueing/Policing an Aggregation/Hubs, Wholesale-Fairness definieren.
• Resilienz nachweisen: Dual-Uplinks, SRLG-Diversität, Maintenance Mode, Failover- und Churn-Tests.
• Observability-by-Design: Pflichtmetriken für OLT/Aggregation/BNG, High-Signal Alerts, Runbooks, Telemetry-Limits.
• Progressive Rollouts: Ausbaugebiete als Canary nutzen, Stop/Go Gates, getesteter Rollback und Evidence-by-Design als Standard.