Site icon bintorosoft.com

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

Red Snapper

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.

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.

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.

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.

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.

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.

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.

Ein pragmatisches N-1-Scale-Kriterium

BNG_Capacity≥Peak_Sessions/(N–1) +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?

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.

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.

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).

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.

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).

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

Exit mobile version