Host-Schnittstellen Standard des SFP-Steckplatzes - SGMII oder HSGMII ?

[Snugel]

Guten Tag.

Kann mir bitte jemand sagen, ob der SFP-Steckplatz am 1800EF als Host-Schnittstelle die Standards SGMII oder HSGMII unterstützt?

Die Foren Suche habe ich bemüht, bin aber nicht fündig geworden. Google
und ChatGPT liefern auch nichts Brauchbares.

Ein GPON von Lancom besagt in den Specs das 2.5GE/1GE unterstützt wird. Das legt die Vermutung nahe, dass HSGMII unterstützt wird. Sicher bin ich mir aber eben nicht.
Die Pinbelegung wird in der SFP-MSA INF-8074i standardisiert oder beschrieben. Es garantiert aber nicht automatisch, dass jedes beliebige Protokoll auf den seriellen TX/RX-Paaren verstanden wird.
Die wichtigsten Pins sind ausschnittsweise wie folgt:
Pin 04 SDA
Pin 05 SCL
Pin 06 MOD_ABS
Pin 08 RX_LOS
Pin 12 RD−
Pin 13 RD+
Pin 18 TD+
Pin 19 TD−

bei entsprechender 3,3-V-Versorgung

Hier die vollständige Pinbelegung:
Pin 01 VEET
Pin 02 TX Fault High
Pin 03 TX Disable High
Pin 04 SDA
Pin 05 SCL
Pin 06 MOD_ABS
Pin 07 Dying Gasp Up to host pin definition
Pin 08 RX_LOS High
Pin 09 VEER
Pin 10 VEET
Pin 11 VEER
Pin 12 RD-
Pin 13 RD+
Pin 14 VEER
Pin 15 VCCR
Pin 16 VCCT
Pin 17 VEET
Pin 18 TD+
Pin 19 TD-
Pin 20 VEET


Soweit ich die Dokus zum 1800EF eingesehen habe, habe ich nichts zu den Standards SGMII oder HSGMII gefunden.

Sollte jemand eine Lösung haben, die Dokumentiert ist, bitte ich um einen Link als Nachweis.

Hintergrund ist die Anschaffung eines GPON von Allnet. Es soll der Allnet ALL-BM510-GPON-GBIC werden.

Lancom selbst sagt dazu nur: "Support zu Fremdherstellerzubehör (SFP und DAC) ist ausgeschlossen."
Das schließt aber nicht aus das Fremdhersteller-SFPs nicht funktionieren.

Fazit: Nicht in der Kompatibilitätsliste ist keine technische Inkompatibilitätsaussage.

Folgendes habe ich in meinen Informationen mehrheitlich selbst zusammengetragen und durch ChatGPT tabellarisch aufbereiten und ergänzen lassen:

Excel.png

Viele Grüße und ein Dank im Voraus
Snugel

[Snugel]

Eventuell habe ich doch noch etwas gefunden.

SoC des LANCOM 1800EF:
Wenn es stimmt dann hat der LANCOM 1800EF einen NXP LS1023E, Dual-Core, 1,4 GHz, 1 GB RAM und die LS1023-Plattform.
Link: fragen-zur-lancom-systems-routern-und-g ... ml#p117523

NXP schreibt dazu:
bis zu 4 × SGMII mit 1.000 Mbit/s
bis zu 2 × SGMII mit 2.500 Mbit/s
QSGMII
XFI
1000BASE-KX
Link: https://community.nxp.com/pwmxy87654/at ... S1043A.pdf

Das besagt nun das das der LS1023 technisch in der Lage ist, nicht aber die konkrete LANCOM-Platinenbeschaltung. Die SerDes-Ressourcen sind verfügbar.
Da der LANCOM GPON-1 offenbar als 1000BASE-X läuft, wird es wesentlich interessanter. Denn das GPON-1 verwendet dort IEEE Clause 37 Auto-Negotiation. Das ist wahrscheinlich der wichtigste Fund. Der SFP-Standard besagt in dem Fall nichts brauchbares.
Der GPON-SFP ist intern eine Ethernet↔GPON-Bridge. Die Ethernetseite zwischen Router und Modul arbeitet mit 1000BASE-X. Da LANCOM das Verhalten seiner unterstützten GPON-Module kennt, wurde das so in LCOS eingebaut/programiert.

Beim Allnet BM510 wird es sehr interessant. Den Allnet schreibt:

• Standard-SFP-Package

• SGMII-Schnittstelle

• SFP-basierte HSGMII-Schnittstelle

• 2,5GE/1GE kompatibel

ALLNET sagt auch im Beschreibungstext das G-97S als zugrunde liegendes GPON-System eingesetzt wird. Die Frage ob LANCOM mit SGMII oder HSGMII umgehen kann ist nicht mehr interessant. Das BM510 von Allnet basiert auf dem CIG G-97S. Hack-GPON führt den CIG G-97S als ODM-Produkt und im miniONT-SFP-Format und identifierziert das Gerät als Realtek RTL9601CI.
Ein baugleich bzw. als G-97S vertriebenes Nokia G-010S-Q wird ebenfalls mit diesem ODM-Code aufgeführt. Das passt sehr gut zu ALLNETs eigener Produktbeschreibung. Allnet verwendet die Bezeichnung G-97S in der integrierten GPON-MAC-/OMCI-Funktions Beschreibung.
Ein bekannter GPON-ONT-SoC, für den HSGMII-Unterstützung dokumentiert ist, ist der RTL9601CI.
Entscheident ist das G-97S ursprünglich mit 1000BASE-X ausgeschrieben wurde.
Ein sehr altes CIG G-97S-Datenblatt Link:
https://github.com/yuvadm/ftth-il/blob/ ... eet_V2.pdf
besagt das: „G-97S ONT is deliverd with on SFP (Small Form-factor Pluggable) based 1000 Base-X Gigabit Ethernet data interface“.
In den Sepc steht auch: GPON Interface Compliant with ITU-T G.984 GPON standrad und als conector wird SC/APC beschrieben. Ein weiterer Punkt ist in den Ethernet-Spec: "SFP based 1000 Base-X GbE interface"
Jetzt schließt sich der Kreis.

• LANCOM-Seite: SFP-GPON-1 → 1000BASE-X + Clause 37 → LANCOM > Link: fragen-zur-lancom-systems-routern-und-g ... 19557.html

• G-97S-Seite: G-97S → 1000BASE-X GbE → SFP Host > Link: https://github.com/hwti/G-010S-A/issues ... 1013783786

Warum sagt ALLNET und auch andere dann SGMII/HSGMII?
Ich kann mir das nur so erklären. SGMII und 1000BASE-X sind nicht dasselbe. Der Linux-Kernel beschreibt SGMII ausdrücklich als Modifikation von 1000BASE-X > Link: https://www.kernel.org/doc/html/v5.13/n ... g/phy.html
Beide verwenden bei 1 Gbit/s eine 1,25-GBaud-SerDes-Verbindung mit 8b/10b-Codierung. SGMII ist eine Modifikation von 1000BASE-X laut Linux-Kernel.
Beim RTL9601CI/G-97S-Umfeld gibt es aber mehrere Varianten und Firmwarekonfigurationen. Andere Geräte auf derselben Realtek-Plattform verfügen beispielsweise über Auto-Sensing bzw. Modi zwischen SGMII und HSGMII. Die Unterstützung hängt teilweise von der konkreten Firmware ab.

Daher geh ich nun davon aus, dass der BM510/G-97S seine Host-SerDes abhängig von Konfiguration/Firmware in unterschiedlichen Betriebsarten betreiben kann. ALLNET beschreibt die Produktfamilie heute als SGMII/HSGMII und 1GE/2,5GE, während ältere G-97S-Unterlagen den 1G-SFP-Betrieb als 1000BASE-X bezeichnen.
Das ist eine Schlussfolgerung aus den verfügbaren Unterlagen, keine explizite ALLNET-Aussage.

Meine Schlussfolgerung:
LANCOM scheint seine GPON-SFP-Verbindung standardmäßig über 1000BASE-X abzuwickeln.

Eine letzte Frage bleibt aber. Schaltet der aktuelle ALL-BM510-GPON-GBIC im 1GE-Modus seine Host-Schnittstelle auf 1000BASE-X mit einer zum LANCOM passenden Clause-37-Signalisierung?
Ein positives indiz ist:
Das dem ALLNET zugrunde liegende G-97S historisch ausdrücklich als 1000BASE-X-GbE-SFP spezifiziert wurde - ich verweise auf den Link oben zu Guthub. Schätze ich die Wahrscheinlichkeit inzwischen höher ein.
Wenn der aktuelle BM510 im 1GE-Modus tatsächlich den historischen G-97S-1000BASE-X-Modus verwendet, sehe ich auf der Host-Seite praktisch keine fundamentale Inkompatibilität mehr.

Ein verbleibendes Risiko: LCOS-Modulerkennung. LCOS enthält offensichtlich LANCOM modulspezifische Logik für die von LANCOM unterstützten GPON-Module. Laut Forum erkennt LCOS das Verhalten dieser Module. Leider ergebne sich daraus weitere Fragen:

• Ethernet-Link BM510 ↔ LANCOM kommt hoch?

• LCOS behandelt das Fremdmodul vollständig wie sein eigenes PON-Modul?

Für den Internetzugan ist Punkt zwei eventuell nicht relevant. Vorraussetzung ist: dass das BM510 als autonomes ONT arbeitet und auf der Hostseite schlicht Ethernet liefert. So könnte LCOS es effektiv wie ein Ethernet-SFP behandeln.
ALLNET bewirbt das BM510 genau für den Einsatz in SFP-basierten Routern, Switches und Gateways.
Zur ersten Frage: Die speziellen LANCOM-Funktionen unter Status/PON, das Schreiben eines PLOAM-Passworts durch LCOS usw. könnten bei einem Fremdmodul dagegen fehlen.

Fazit:
Durch die letzten Recherchen und Auswertungen mein Dank gebührt ChatGPT denn ChatGPT hat das PDF - https://github.com/yuvadm/ftth-il/blob/ ... eet_V2.pdf - ausfindig gemacht, bin ich nun einen erheblichen Schritt weiter.

• Der 1800EF verwendet sehr wahrscheinlich einen NXP LS1023A/E. Link: fragen-zur-lancom-systems-routern-und-g ... 20510.html

• Dieser SoC unterstützt 1G-SGMII und 2,5G-SGMII nativ. Link: https://community.nxp.com/pwmxy87654/at ... S1043A.pdf

• Das beweist aber nicht, dass LANCOM den SFP-Cage als SGMII betreibt.

• Im Gegenteil: LANCOMs GPON-1 wird laut sehr detaillierten Praxisangaben als 1000BASE-X mit Clause 37 betrieben. Link: fragen-zur-lancom-systems-routern-und-g ... 19557.html

• Das ALLNET BM510 nennt intern G-97S, und das historische CIG-G-97S-Datenblatt spezifiziert die Hostseite ebenfalls als 1000BASE-X GbE. Link: https://shop-en.allnet.de/Products/Tele ... dge-Modem/

• Genau das ist ein starkes Argument für die Kompatibilität.

Der letzte Beweis der fehlt ist:
Welchen Host-Modus verwendet genau die aktuelle ALL-BM510-Firmware bei 1 Gbit/s: echtes SGMII oder 1000BASE-X/Clause 37?

Wenn ich diese eine Frage abschließend klären könnten, ist die Frage der Host-Kompatibilität in meinen Augen geklärt.


Viele Grüße und ein Dank im Voraus
Snugel

[fildercom]

Ich hatte vor kurzem eine ähnliche Fragestellung, allerdings zum LANCOM GPON-Modul:
fragen-zur-lancom-systems-routern-und-g ... 21525.html

[rotwang]

Warum sagt ALLNET und auch andere dann SGMII/HSGMII?

Ungefähr 90% der Welt bekommt 1000BASE-X und SGMII nicht auseinander gehalten. Unter anderem deshalb, weil sie sich so extrem ähnlich und die Unterschiede so subtil sind.

Bei 1000BASE-X (mit aktivierter Clause 37 Negotiation) schicken zwei PHYs sich gegenseitig Config-Pages und handeln Link-Parameter aus. Die Geschwindigkeit und Duplex-Betrieb liegen aber von vornherein fest, so dass das Aushandeln sich auf eher 'sekundäre Features' wie Flow Control beschränkt. Der andere Vorteil von aktivierter Clause 37: man kann keine einseitigen Links bekommen, wenn eine Richtung bzw. eine Faser unterbrochen ist. Beide Seiten ziehen den Link-Status erst hoch, wenn ihre Config-Pages von der Gegenseite bestätigt wurde.

Bei SGMII hat ein grosser Hersteller von Netzwerk-Equipment den Physical Layer von 1000BASE-X 'recycelt', um eine Leitungen sparende, geräteinterne Verbindung zwischen einem Ethernet-MAC und einem Ethernet-PHY zu definieren. Hier führt nur der PHY die Auto-Negotiation, und das Ergebnis teilt er über Config-Pages dem MAC mit. Diese Config-Pages sind auch anders belegt. Ein zweites Extra-Feature von SGMII ist das Bit-Stuffing: Hat der PHY mit der Gegenseite eine Link-Geschwindigkeit von 10 oder 100 Mbps ausgehandelt, dann werden alle Daten-Bits zehn- oder hundertmal wiederholt. Die physische Bitrate auf der Leitung bleibt also immer bei 1 Gbps, bzw. 1,25 Gbps mit Kodierungs-Overhead.

SGMII ist übrigens kein von IEEE 802.3 definierter Standard, nur ein weit verbreiteter Industriestandard.

Bei 2,5 Gbps, so genanntes "HSGMII" oder "Turbo-SGMII" wird die Sache noch kniffliger, weil dann überhaupt keine Auto-Negotiation definiert ist, auch kein Bit Stuffing. Der Unterschied zwischen HSGMII und einem (hypothetischen) 2500BASE-X wird noch kleiner. Die Lösungen, die ich kenne, wo ein MAC und ein PHY per HSGMII verbunden sind, schalten die Bitrate auf den Leitungen auf 2,5Gbps um, wenn der PHY mit der Gegenstelle 2,5 Gbps ausgehandelt hat. Für 10/100/1000 bleibt es bei 'normalem' SGMII und dem optionalen Bit-Stuffing.

Der SFP-Port am 1800EF unterstützt 1000BASE-X, wahlweise mit oder ohne Clause 37 Auto Negotiation. Das ist das, was man für den Betrieb mit Fasermodulen auch braucht. GPON-Module emulieren üblicherweise Fasermodule, damit man sie in dafür ausgelegten SFP-Steckplätzen betreiben kann. Manche von ihnen probieren beim Start aus, ob die Gegenseite Bits mit 2,5 oder 1 Gbps sendet und passen sich darauf an. Das LANCOM GPON-1 gehört wohl auch dazu, davon wird in LANCOM-Routern aber kein Gebrauch gemacht,

Der SFP-Port im 1800EF unterstützt weder SGMII noch HSGMII, die Rate liegt also fix auf 1 Gbps. Es ist richtig, dass die NXP-CPU auch SGMII und 2,5 Gbps unterstützt, aber das wird durch ein "Reset Configuration Word" festgelegt und ist nicht zur Laufzeit umschaltbar. Intern sind z.B. der WAN-Ethernet-PHY und der Switch, der ETH-1...ETH-4 bedient, per SGMII angebunden, aber das ist wie gesagt eine geräteinterne Verbindung und genauso fix.

SGMII an einem extern zugänglichen SFP-Port hat aber sowieso nur begrenzte Anwendungsmöglichkeiten. Die einzige, die ich kenne, ist ein Kupfer-SFP-Modul, wo man durch das Bit-Stuffing-Feature einen 'vollwertigen' Ethernet-Port mit allen drei Geschwindigkeiten bekommt. Ohne SGMII kann so ein Kupfer-SFP-Modul nur die 1Gbps von 1000BASE-X durchreichen, und auf der Kupfer-Leitung gehen keine 10 oder 100 Mbps. Das ist aber Teil eines anderen Themas, zu dem es an anderer Stelle hier einen ausführlichen Post gibt.

Alles übrigens ohne KI-Hilfe geschrieben. Ich mag hier im Forum lieber mit Menschen als mit Maschinen reden...

[rotwang]

Bezüglich Fremdhersteller GPON-Modulen gilt das gleiche wie bei Fremdhersteller-Fasermodulen: Das LCOS hat keine expliziten Vendor-Locks, aber wenn's nicht funktioniert, hat man auch niemanden, bei dem man sich beschweren kann.

Bei GPON-Modulen kommt noch hinzu, dass die ganzen Menüs im LCOS unter Setup/Interfaces/PON und Status/PON nur für LANCOM-Module funktionieren. Das LCOS 'kennnt' nur die Management-Schnittstellen dieser Module. Fall man im GPON-Modul irgendetwas umstellen muß, um eine PON-Verbindung zum Provider zu bekommen, muß man selber heraus finden, wie man per Telnet/SSH/HTTP auf die Management-Schnittstelle kommt. Da können dann ähnliche Tricks erforderlich sein wie bei externen DSL-Modems an einem Ethernet-Port.

[Jirka]

Hallo,

sehr interessant, was hier alles zu lesen ist. Und in einer Tiefe, die ja nun auch nicht jeden Tag hier im Forum zu lesen ist. Respekt.

Allerdings frage ich mich ehrlich:

Hintergrund ist die Anschaffung eines GPON von Allnet.

Wieso betreibst Du wegen eines GPON-Moduls so einen zeitlichen Aufriss und kaufst nicht einfach das entsprechende GPON-Modul von LANCOM?! Da wird doch die Allnet-Lösung zigfach teurer und am Ende funktionieren kleine Details noch nicht mal, wie rotwang schon schrieb.

Alles übrigens ohne KI-Hilfe geschrieben. Ich mag hier im Forum lieber mit Menschen als mit Maschinen reden...

Na ja, er hat ja auch noch selber geschrieben, er hat eben nur schon versucht, das Problem selber mit KI-Hilfe zu lösen oder seine Fragestellungen zu klären. Wart mal erst ab, bis hier die ersten wirklich KI-generierten Fragen im Forum erscheinen. So lange kann das nicht mehr dauern. Ich habe vor kurzem in einem Zeitungsartikel gelesen, dass Behörden überlastet sind, weil viele KI-generierte Widersprüche oder Einsprüche eingegangen sind, die alle bearbeitet werden müssen. Konkrete Zahlen gab es da für irgendwelche Bürgergeld-Bescheide. Allerdings waren offenbar 25 % der KI-generierten Einsprüche korrekt und die Behörden mussten denen stattgeben. Was mich an der Sache nur wunderte: Offenbar nutzen die Bürgergeld-Empfänger die KI öfter als man vermuten würde.

[fildercom]

Auch ich möchte mich bei rotwang sehr herzlich für das super detaillierte Posting bedanken, das ist wirklich große Klasse!