Re: What is inside GPON SFP module?

From: Hauke Mehrtens
Date: Sat Jun 05 2021 - 10:17:57 EST

On 6/5/21 3:31 PM, Pali Rohár wrote:
On Saturday 05 June 2021 15:04:55 Hauke Mehrtens wrote:
On 6/5/21 2:50 PM, Pali Rohár wrote:
On Saturday 05 June 2021 15:26:39 Vladimir Oltean wrote:
On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:
It started out as described - literally, 1000base-X multiplied by 2.5x.
There are setups where that is known to work - namely GPON SFPs that
support 2500base-X. What that means is that we know the GPON SFP
module negotiates in-band AN with 2500base-X. However, we don't know
whether the module will work if we disable in-band AN.

Pardon my ignorance, but what is inside a GPON ONT module? Just a laser
and some amplifiers? So it would still be the MAC PCS negotiating flow
control with the remote link partner? That's a different use case
from
a
PHY transmitting the negotiated link modes to the MAC.

Hello Vladimir! All GPON ONU/ONT SFP modules which I have tested, are
fully featured mini computers. It is some SoC with powerful CPU, fiber
part, at least two NICs and then two phys, one for fiber part and one
for "SFP"-part (in most cases 1000base-x or 2500base-x). On SoC inside
is running fully featured operating system, in most cases Linux kernel
2.6.3x and tons of userspace applications which implements "application"
layer of GPON protocol -- the most important part. If OEM vendor of GPON
SFP stick did not locked it, you can connect to this "computer" via
telnet or web browser and configure some settings, including GPON stuff
and also how GPON network is connected to SFP part -- e.g. it can be
fully featured IPv4 router with NAT or just plain bridge mode where
"ethernet data packets" (those which are not part of ISP configuration
protocol) are pass-throw to SFP phy 1000base-x to host CPU. GPON is not
ethernet, it is some incompatible and heavily layered extension on ATM.
Originally I thought that ATM is long ago dead (as I saw it in used last
time in ADSL2) but it is still alive and cause issues... I think it does
not use 8b/10b encoding and therefore cannot be directly mapped to
1000base-x. Also GPON uses different wavelengths for inbound and
outbound traffic. And to make it even more complicated it uses totally
nonstandard asynchronous speeds, inbound is 2488.32Mbit/s, outbound is
1244.16Mbit/s. So I guess CPU/SoC with GPON support (something which is
inside that GPON ONU/ONT stick) must use totally different modes for
which we do not have any option in DTS yet.

So once mainline kernel will support these "computers" with GPON support
it would be required to define new kind of phy modes... But I do not
think it happens and all OEM vendors are using 2.6.3x kernels their
userspace GPON implementation is closed has tons of secrets.


Hi,

This description of the GPON SFP sticks is correct, but it misses some
of
the complexity. ;-) GPON is also a shared medium like DOCSIS, you can not
always send, but you have to wait till you get your time slice over PLOAM.

Hello!

I think same applies also for 1000BASE-PX or 10GBASE-PR GEPON passive
ethernet networks (Beware GPON != GEPON).

There is one family standardized by the ITU (GPON, XGPON, XGSPON, NGPON2) and an other family standardized by the IEEE (EPON, GEPON). They solve more or less the same problem, just in a different way.

But I think this is not an issue. There are also other "shared medium"
technologies (e.g. mobile network; or WiFi on DFS channels) for which
exists hardware supported by mainline kernel (3G/LTE modems).

Yes, then you just need a MAC which can handle it. It is more complex than a normal Ethernet MAC.

In addition the GPON SFP stick also have to talk the OMCI protocol which
allows to operator to configure all sorts of layer 2 things. They can also
login to your SFP stick. ;-)

Yes, I just described it as "application" layer. It is complicated and
basically something which is not suppose to be implemented in kernel.
Plus GPON vendors extends (standardized) OMCI protocol with their own
extension which means that without their implementation on client side
it is impossible to fully establish connection to "server" OLT part.

You can use one software stack without (many) vendor OLT specific workarounds which works with multiple of the big OLT vendors. The OMCI protocol definition is also publicly available and there are no vendor extensions needed for normal operations nowadays. The specification leaves room for interpretation in some parts and some OMCI ONU stacks are "optimized" for a specific OLT vendor.

There are also some passive GPON SFP sticks which just translate between
electrical and optical signals, but to operate them you need a GPON MAC and
managed layer on your host.

Interesting... Do you know where to buy or test such passive GPON SFP sticks?

Most of the 10€ GPON OLT sticks are such passive sticks, but the wavelengths are in the wrong order.

I do not know where exactly to buy them, but there are multiple vendors building such sticks. To operate them on a GPON fiber you still need the GPON MAC.

And is there some documentation how these sticks works? And what kind of
phy mode they are using over SerDes? Because due to different inbound
and outbound speeds it cannot be neither 1000base-x nor 2500base-x.

I do not know.

Adding GPON support properly into Linux is not an easy task, Linux would
probably need a subsystem with a complexity compared to cfg80211 + hostapd.

Yea... But maybe it could be easier to implement just "client part"
(ONU/ONT) without "server part" (OLT).

Yes, the ONU and OLT part are pretty different on the Management layer anyway.

Is there a list of things these GPON sticks running Linux should do better
in the future? For example what to avoid in the EEPROM emulation handling?

Well... If you think that it is possible to address these issues
directly to GPON vendors and they will fix them in next version of GPON
SFP sticks, I could try to find some time and prepare list of lot of
issues...

I can not promise that, but I can try.
There are some constrains like the EEPROM is only available after the Linux booted up, so it takes some time after it got power.

Hauke

Attachment: OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature