diff --git a/gpon/epon-standard.md b/gpon/epon-standard.md
new file mode 100644
index 00000000..953bc65b
--- /dev/null
+++ b/gpon/epon-standard.md
@@ -0,0 +1,183 @@
+---
+title: EPON IEEE 802.3ah/av Series
+has_children: false
+nav_order: 5
+---
+
+The information on this page is taken from the IEEE 802.3 EPON standard and from the presentations of the IEEE P802.3av and NG-EPON task forces, each individual item containing a verifiable citation. Feel free to cite this page as: .
+
+EPON (Ethernet Passive Optical Network) is the IEEE alternative to the ITU-T GPON/XGS-PON family[^ieee-xplore]. While GPON wraps Ethernet frames inside its own transmission convergence layer (GEM), EPON carries native Ethernet frames over the same point-to-multipoint passive optical network: the OLT and the ONUs are Ethernet stations and the PON specific functions are added as an extension of the Ethernet MAC and PHY layers[^802.3-2015].
+
+# Standards
+
+| Standard | Year | Name | Clauses | Downstream / Upstream |
+| --------------------------- | ---- | ------------------------- | ------------------------------------------------------------- | --------------------- |
+| IEEE 802.3ah | 2004 | 1G-EPON (EFM) | 56-67: PMD (60), MPCP (64), RS/FEC (65), OAM (57) | 1 / 1 Gb/s |
+| IEEE 802.3av | 2009 | 10G-EPON | 75: PMD, 76: RS/PCS/PMA, 77: MPCP, Annex 75A: coexistence | 10 / 1 or 10 / 10 Gb/s |
+| IEEE 802.3bk | 2013 | Extended EPON | adds the PX30, PX40, PRX40 and PR40 power budgets | |
+| IEEE 802.3-2015 (Section 5) | 2015 | Consolidated EPON clauses | 1G-EPON and 10G-EPON merged into the base standard[^802.3-2015] | |
+| IEEE 802.3ca | 2020 | 25G/50G-EPON (NG-EPON) | 141-144 | 25 or 50 / 10, 25 or 50 Gb/s |
+| IEEE 1904.1 (SIEPON) | 2013 | Service Interoperability | system level management, see [SIEPON](#siepon-and-the-management-of-the-onu) | |
+
+IEEE 802.3 only defines the physical layer, the multipoint MAC control and the basic OAM: it does not define how an ONU is provisioned (VLANs, services, VoIP, etc.). This part, which in GPON is covered by OMCI, is defined by the operators and by IEEE 1904.1 (SIEPON).
+
+# Protocol stack
+
+EPON reuses the Ethernet layers and adds a Multipoint MAC Control (MPMC) sublayer and an extension of the Reconciliation Sublayer (RS), in order to emulate a point-to-point link for each ONU over the point-to-multipoint plant[^hajduczenia-av].
+
+```mermaid
+graph TD
+ subgraph OLT
+ A1[MAC Client / OAM] --- A2[MPMC - MPCP Clause 64/77]
+ A2 --- A3[MAC one per LLID]
+ A3 --- A4[RS - Clause 65/76]
+ A4 ---|GMII / XGMII| A5[PCS - PMA]
+ A5 --- A6[PMD - Clause 60/75]
+ end
+ subgraph ONU
+ B6[PMD - Clause 60/75] --- B5[PCS - PMA]
+ B5 ---|GMII / XGMII| B4[RS - Clause 65/76]
+ B4 --- B3[MAC]
+ B3 --- B2[MPMC - MPCP Clause 64/77]
+ B2 --- B1[MAC Client / OAM]
+ end
+ A6 ---|ODN| B6
+```
+
+In the asymmetric 10/1G-EPON the OLT uses the XGMII in the transmit path and the GMII in the receive path, while the ONU does the opposite: each interface is used in a single direction only[^hajduczenia-av].
+
+## LLID and point-to-point emulation
+
+Every logical link between the OLT and an ONU is identified by a 15 bit LLID (Logical Link IDentifier), assigned by the OLT during the registration. The LLID and a mode bit are carried inside the Ethernet preamble, which is partially replaced and protected by a CRC8: in this way the frames stay standard Ethernet frames while each ONU can discard the frames not addressed to it[^802.3-2015]. The broadcast LLID is `0x7FFF` for 1G-EPON and `0x7FFE` for 10G-EPON.
+
+An example of a captured 10G-EPON preamble is shown in the [Free/Iliad](/epon/free_iliad) page.
+
+## MPCP (Multi-Point Control Protocol)
+
+The upstream is shared in TDMA: the OLT decides when each ONU can transmit. MPCP is a MAC Control protocol with five messages (MPCPDUs)[^hajduczenia-av]:
+
+| MPCPDU | Direction | Usage |
+| -------------- | ---------- | ------------------------------------------------------------------------------------------------------ |
+| `GATE` | OLT → ONU | grants a transmission window; the *Discovery GATE* opens a discovery window for the unregistered ONUs |
+| `REPORT` | ONU → OLT | reports the queue status of the ONU, used by the DBA |
+| `REGISTER_REQ` | ONU → OLT | registration request sent in the discovery window, it carries the MAC address of the ONU |
+| `REGISTER` | OLT → ONU | assigns the LLID to the ONU |
+| `REGISTER_ACK` | ONU → OLT | confirms the registration |
+
+```mermaid
+sequenceDiagram
+ participant OLT
+ participant ONU
+ OLT->>ONU: Discovery GATE (broadcast LLID)
+ ONU->>OLT: REGISTER_REQ (ONU MAC address, random delay)
+ OLT->>ONU: REGISTER (assigned LLID)
+ OLT->>ONU: GATE (unicast grant)
+ ONU->>OLT: REGISTER_ACK
+ Note over OLT,ONU: OAM discovery, then authentication and provisioning (extended OAM)
+```
+
+In 10G-EPON (Clause 77) the Discovery GATE and the REGISTER_REQ have a new *Discovery Information* field, so that a dual-rate OLT can open separate 1G and 10G discovery windows and the ONU can declare whether it is 1G and/or 10G upstream capable. REGISTER_REQ and REGISTER also carry the laser on/off times of the ONU[^hajduczenia-av].
+
+Since the ONU is identified by its MAC address during the registration, the MAC address in EPON plays the role of the GPON serial number: the OLT can authenticate the ONU by MAC address, or by LOID (Logical ONU ID) and password through the extended OAM (see below).
+
+# Physical layer
+
+## Coding, line rate and FEC
+
+| Parameter | 1G-EPON | 10G-EPON | 25G/50G-EPON |
+| --------------- | -------------------------------- | ------------------------------------------------ | --------------------- |
+| Line coding | 8b/10b | 64b/66b | 64b/66b |
+| Line rate | 1.25 GBd | 10.3125 GBd | 25.78125 GBd per wavelength |
+| MAC interface | GMII | XGMII (GMII for the 1G direction of 10/1G-EPON) | 25GMII |
+| FEC | RS(255,239), optional, frame based | RS(255,223), mandatory, stream based | LDPC |
+
+In 10G-EPON the FEC is always enabled and stream based: the overhead is constant (12.9%), it is accommodated by deleting the extra IDLE characters in the PCS, so that the XGMII and the line rate are not super-rated. The burst mode PMA adds a synchronization pattern and the *Start_of_Burst* and *End_of_Burst* delimiters[^hajduczenia-av].
+
+## PMD and power budgets
+
+The PMD names follow a simple rule[^hajduczenia-av]:
+
+- `P` stands for PON;
+- `X` stands for 8b/10b coding, `R` for 64b/66b coding (`PRX` is asymmetric: 64b/66b downstream, 8b/10b upstream);
+- the number after the letters is the power budget (`10`, `20`, `30`, ...) in 1G-EPON or the configuration (`1`, `2`, `3`) in 10G-EPON;
+- `D` is the OLT (downstream) side, `U` is the ONU (upstream) side.
+
+For example `1000BASE-PX20-U` is a 1G-EPON ONU with the 20 power budget, while `10/1GBASE-PRX-U2` is an asymmetric 10G-EPON ONU with the PRX20 power budget.
+
+| Power budget | Standard | Downstream | Upstream | Max ChIL | Min ChIL | Nominal reach / split |
+| ------------- | -------- | ---------------------- | ---------------------- | -------- | -------- | --------------------- |
+| PX10 | 802.3ah | 1.25 GBd, 1490 nm | 1.25 GBd, 1310 nm | 20 dB | 5 dB | 10 km 1:16 |
+| PX20 | 802.3ah | 1.25 GBd, 1490 nm | 1.25 GBd, 1310 nm | 24 dB | 10 dB | 20 km 1:16 |
+| PRX10 | 802.3av | 10.3125 GBd, 1577 nm | 1.25 GBd, 1310 nm | 20 dB | 5 dB | 10 km 1:16 |
+| PRX20 | 802.3av | 10.3125 GBd, 1577 nm | 1.25 GBd, 1310 nm | 24 dB | 10 dB | 20 km 1:16 |
+| PRX30 | 802.3av | 10.3125 GBd, 1577 nm | 1.25 GBd, 1310 nm | 29 dB | 15 dB | 20 km 1:32 |
+| PR10 | 802.3av | 10.3125 GBd, 1577 nm | 10.3125 GBd, 1270 nm | 20 dB | 5 dB | 10 km 1:16 |
+| PR20 | 802.3av | 10.3125 GBd, 1577 nm | 10.3125 GBd, 1270 nm | 24 dB | 10 dB | 20 km 1:16 |
+| PR30 | 802.3av | 10.3125 GBd, 1577 nm | 10.3125 GBd, 1270 nm | 29 dB | 15 dB | 20 km 1:32 |
+
+The nominal reach and split are informative only: devices that exceed them are still compliant. PRX30 has no 1G-EPON counterpart in 802.3ah[^hajduczenia-av].
+
+## Wavelength plan
+
+| Signal | Band |
+| ------------------------ | ----------------------------- |
+| 1G-EPON downstream | 1480 - 1500 nm |
+| 1G-EPON upstream | 1260 - 1360 nm (wideband), 1290 - 1330 nm (narrowband) |
+| 10G-EPON downstream | 1575 - 1580 nm |
+| 10G-EPON upstream (PR) | 1260 - 1280 nm |
+| 10G-EPON upstream (PRX) | 1260 - 1360 nm (1G upstream) |
+| RF video overlay | 1550 - 1560 nm |
+
+Note that the 10G-EPON downstream (1577 nm) and upstream (1270 nm) wavelengths are the same as XGS-PON, while the 1G-EPON wavelengths are the same as GPON: for this reason an EPON and a GPON ONU can have the same optics but they are not interchangeable, since the line coding and the protocol are different.
+
+## Coexistence of 1G-EPON and 10G-EPON
+
+10G-EPON is designed to coexist with 1G-EPON on the same ODN (Annex 75A)[^hamano],[^hajduczenia-ng]:
+
+- **downstream**: the 1G and 10G signals are WDM multiplexed (1490 nm and 1577 nm), so they are independent;
+- **upstream, TDM coexistence**: the 1G and 10G ONUs share the 1260-1360 nm band in TDMA, and the OLT has a dual-rate burst-mode receiver that detects the rate of each burst at the PHY layer; this is required by the wideband 1G-EPON ONUs (Fabry-Perot lasers);
+- **upstream, WDM coexistence**: with narrowband 1G-EPON ONUs (DFB lasers, 1290-1330 nm) the 1G and 10G OLT ports can be separate and WDM multiplexed, so that both upstream channels are independent.
+
+| Dual-rate operation | OLT PMD | ONU PMDs on the same ODN |
+| -------------------------------- | --------------------------------------- | ------------------------------------------------------- |
+| Downstream | 1000BASE-PX-D + 10/1GBASE-PRX-D | 1000BASE-PX-U, 10/1GBASE-PRX-U |
+| Upstream | 10GBASE-PR-D + 10/1GBASE-PRX-D | 10GBASE-PR-U, 10/1GBASE-PRX-U |
+| Downstream and upstream | 1000BASE-PX-D + 10GBASE-PR-D | 1000BASE-PX-U, 10/1GBASE-PRX-U, 10GBASE-PR-U |
+
+Only the PMDs with a compatible power budget can be connected to the same ODN[^hamano].
+
+# SIEPON and the management of the ONU
+
+IEEE 802.3 defines a basic OAM (Clause 57, *Slow Protocol* with Ethertype `0x8809`), used for link monitoring and loopback, which can be extended with organization specific TLVs. The provisioning of the ONU (bridging, VLANs, multicast, voice, firmware upgrade, etc.) is carried in these extended OAM messages, and it is different for each family of networks. IEEE 1904.1 (SIEPON) collects them in three packages:
+
+| Package | Origin | Notes |
+| ----------------- | ------------------------------------------- | ----------------------------------------------------------------------------------- |
+| SIEPON Package-A | DPoE (DOCSIS Provisioning over EPON), CableLabs | used by cable operators, the ONU is managed like a DOCSIS cable modem, encryption with 802.1AE (MACsec) |
+| SIEPON Package-B | NTT (Japan) | |
+| SIEPON Package-C | CTC (China Telecom) | the most common on the market, authentication by MAC or LOID and password |
+
+Since the ONU behaviour depends on the extended OAM implemented by the firmware, an ONU of one package does not usually work on a network of another package: for example the [CIG](/epon/CIG) ONUs are sold as SIEPON Package-C, but they can be switched to Package-A by installing a custom firmware.
+
+# Comparison with GPON and XGS-PON
+
+| Feature | 1G-EPON | GPON (G.984) | 10G-EPON | XGS-PON (G.9807.1) |
+| --------------------- | ---------------- | ------------------------- | --------------------- | ------------------------- |
+| Organization | IEEE | ITU-T | IEEE | ITU-T |
+| Downstream | 1.25 GBd (1 Gb/s) | 2.488 Gb/s | 10.3125 GBd (10 Gb/s) | 9.953 Gb/s |
+| Upstream | 1.25 GBd (1 Gb/s) | 1.244 Gb/s | 1.25 or 10.3125 GBd | 9.953 Gb/s |
+| Encapsulation | native Ethernet | GEM | native Ethernet | XGEM |
+| ONU identification | MAC address, LLID | Serial Number, ONU-ID | MAC address, LLID | Serial Number, ONU-ID |
+| Authentication | MAC, LOID/password (CTC) | Serial Number, PLOAM password, LOID (OMCI) | MAC, LOID/password (CTC), certificates (DPoE) | Serial Number, registration ID, LOID |
+| ONU management | extended OAM | OMCI | extended OAM | OMCI |
+| Downstream wavelength | 1490 nm | 1490 nm | 1577 nm | 1577 nm |
+| Upstream wavelength | 1310 nm | 1310 nm | 1270 nm | 1270 nm |
+
+See [GPON G.984 Series](/g_984_series) for the GPON standard.
+
+---
+
+[^802.3-2015]: *IEEE Standard for Ethernet*, IEEE Std 802.3-2015, Section Five https://www.onetel.de/wp-content/uploads/2016/11/802.3-2015_SECTION5.pdf
+[^hajduczenia-av]: Hajduczenia M., *Overview of 10G-EPON*, IEEE P802.3av interim, Shanghai, June 2009 https://grouper.ieee.org/groups/802/3/av/public/2009_06/3av_0906_hajduczenia_1.pdf
+[^hamano]: Hamano H., *75.6 Dual-rate (coexistence) mode*, IEEE P802.3av, November 2008 https://www.ieee802.org/3/av/public/2008_11/3av_0811_hamano_1.pdf
+[^hajduczenia-ng]: Hajduczenia M., *WDM coexistence for 1G/10G/NG-EPON*, IEEE 802.3 NG-EPON Study Group, September 2015 https://www.ieee802.org/3/NGEPONSG/public/2015_09/ngepon_1509_hajduczenia_2.pdf
+[^ieee-xplore]: IEEE Xplore, document 6138784 https://ieeexplore.ieee.org/document/6138784
diff --git a/gpon/g_984_series.md b/gpon/g_984_series.md
index 8fc1a112..2c563993 100644
--- a/gpon/g_984_series.md
+++ b/gpon/g_984_series.md
@@ -16,6 +16,25 @@ The information on this page is taken from the GPON standard and information fro
| | | Alarms / Monitoring | | |
| | | OMCI | | |
+Other recommendations of the series are G.984.5 (enhancement band, wavelengths reserved for the coexistence with the next generation PONs), G.984.6 (reach extension) and G.984.7 (long reach).
+
+## The ITU-T PON family
+
+GPON is the second generation of the ITU-T PONs. The following generations reuse most of its concepts (ONU-ID, Alloc-ID, T-CONT, GEM ports, PLOAM, OMCI), with a different physical layer and a different TC layer (XGTC, XGEM)[^g987],[^g9807]:
+
+| Recommendation | Name | Year | Downstream | Upstream | Downstream wavelength | Upstream wavelength |
+| -------------- | ------------- | ---- | -------------------------- | ------------------------------ | --------------------- | ------------------------------- |
+| G.983 | BPON | 1998 | 622 Mb/s | 155 Mb/s | 1490 nm | 1310 nm |
+| G.984 | GPON | 2003 | 2.48832 Gb/s | 1.24416 Gb/s | 1480 - 1500 nm | 1260 - 1360 nm |
+| G.987 | XG-PON | 2010 | 9.95328 Gb/s | 2.48832 Gb/s | 1575 - 1580 nm | 1260 - 1280 nm |
+| G.9807.1 | XGS-PON | 2016 | 9.95328 Gb/s | 9.95328 Gb/s (or 2.48832 Gb/s) | 1575 - 1580 nm | 1260 - 1280 nm |
+| G.989 | NG-PON2 | 2015 | 4-8 x 9.95328 Gb/s (TWDM) | 4-8 x 2.48832/9.95328 Gb/s | 1596 - 1603 nm | 1524 - 1544 nm |
+| G.9804 | 50G-PON (HSP) | 2021 | 49.7664 Gb/s | 12.44, 24.88 or 49.77 Gb/s | 1340 - 1344 nm | several options, see G.9804.3 |
+
+Since the wavelengths are different, GPON and XGS-PON can share the same ODN: the OLT uses either two ports combined with an external WDM filter (the *coexistence element*, WDM1r, defined in G.984.5), or a single *combo PON* port with both transceivers and the WDM filter integrated in the same optic. Each ONU only sees its own wavelengths, so a GPON ONU keeps working when XGS-PON is added to the same fiber.
+
+The IEEE alternative to the ITU-T PONs is EPON, see [EPON IEEE 802.3ah/av Series](/epon-standard).
+
# General Concepts[^zyxel]
- Bitrate: 1.2 Gbps Upstream; 2.4 Gbps Downstream.
@@ -36,6 +55,33 @@ The information on this page is taken from the GPON standard and information fro
1.24416 Gbps up, 2.48832 Gbps down is the most supported speed combination at current time.
+## Physical layer (G.984.2)[^g9842]
+
+| Parameter | Value |
+| ----------------------- | --------------------------------------------------------------------------------------- |
+| Downstream wavelength | 1480 - 1500 nm (1490 nm) |
+| Upstream wavelength | 1260 - 1360 nm (1310 nm) |
+| Video overlay | 1550 - 1560 nm (RF video, enhancement band defined in G.984.5) |
+| Line coding | NRZ, scrambled with the polynomial x7 + x6 + 1 (no 8b/10b, unlike EPON) |
+| Downstream transmission | continuous, broadcast to all the ONUs |
+| Upstream transmission | burst mode TDMA, the ONU laser is switched on only in its allocated time slots |
+| Fiber | single-mode, ITU-T G.652 |
+| Physical reach | 20 km (10 km for some low budget optics) |
+| Logical reach | 60 km, max differential distance 20 km |
+| Split ratio | up to 1:64 (1:128 at the TC layer) |
+
+The power budget is described by the optical classes. The *Channel Insertion Loss* (ChIL) is the attenuation of the ODN (fiber, splitters, connectors and splices) that the optics must support:
+
+| Class | Min ChIL | Max ChIL | Notes |
+| ----- | -------- | -------- | ----------------------------------------------------------- |
+| A | 5 dB | 20 dB | |
+| B | 10 dB | 25 dB | |
+| B+ | 13 dB | 28 dB | the most common class for the ONUs and the OLTs |
+| C | 15 dB | 30 dB | |
+| C+ | 17 dB | 32 dB | used for longer reach or higher split ratios (e.g. 1:128) |
+
+For example a 1:32 splitter introduces about 17 dB of loss, plus about 0.35 dB/km of fiber at 1310 nm: with a class B+ optic a 1:32 split on 20 km of fiber is within the budget.
+
# GPON Terminology
@@ -102,7 +148,7 @@ Key Terms:
- Physical layer OAM upstream (PLOAMu) - PLOAM messages of upstream data. Think of this as a message-based operation and management channel between the OLT and ONU/ONTs.
- Power level sequence upstream (PLSu) - Upstream power level sequence
- Dynamic bandwidth report upstream (DBRu) - Upstream dynamic bandwidth report
-Payload - User data
+- Payload - User data
- PCBd - Physical Control Block downstream
- OMCC - Optical Network Unit Management and Control Channel
- OMCI - Optical Network Unit Management and Control Interface
@@ -113,7 +159,7 @@ GPON uses two layers of encapsulation:
1. TDM and Ethernet frames are wrapped into GTC Encapsulation Method (GEM) frames, which have a GFP-like format (derived from Generic Frame Procedure ITU G.7401).
The main purpose of the GEM frame is to provide a frame-oriented service, as an alternative to ATM, in order to efficiently accommodate Ethernet and TDM frames. With GEM, all traffic is mapped across the GPON network using a variant of SONET/SDH GFP. GEM natively supports transportation of voice, video, and data without an added ATM or IP encapsulation layer[^medium],[^fs].
-2. ATM and GEM frames are both encapsulated into GTC frames that are finally transported over the PON[^medium],[^fs].
+2. ATM and GEM frames are both encapsulated into GTC frames that are finally transported over the PON[^medium],[^fs]. The ATM transport was defined in the first version of G.984.3, but it has been removed in the 2008 revision and it is not used by the deployed equipment.
ITU-T G.984 defines GEM as the only data transport scheme for GPON. Bandwidth allocation in GPON grants individual transmission opportunities to the ONU's traffic-bearing entities on the timescale of a single GTC frame[^zyxel].
@@ -139,7 +185,7 @@ The OLT broadcasts PCBd to all ONU/ONTs. The ONU/ONTs receive the PCBd and perfo
PCBd consists of the GTC header and BWmap:
- GTC Header - Used for frame delimitation, synchronization, and forward error correction (FEC).
-- BWmap - Field notifies very ONU of upstream bandwidth allocation. Specifies the start and end upstream time slots for the T-CONTs of each ONU. This ensures that all ONUs send data based on the time slots specified by the OLT to prevent data conflict.
+- BWmap - Field notifies every ONU of upstream bandwidth allocation. Specifies the start and end upstream time slots for the T-CONTs of each ONU. This ensures that all ONUs send data based on the time slots specified by the OLT to prevent data conflict.
@@ -167,7 +213,7 @@ In the Upstream channel, GEM traffic is carried over one or more T-CONTs. The OL
- The OLT grants upstream bandwidth allocation.
- The ONU traffic-bearing entities are identified by their Allocations IDs.
- Alloc-IDs are multiplexed in time as specified by the bandwidth-map (provided by the OLT in the downstream frame).
-- Within its bandwidth allocation, the ONU uses the GEM Port-IF as key to identify upstream GEM frames.
+- Within its bandwidth allocation, the ONU uses the GEM Port-ID as key to identify upstream GEM frames.
- Each upstream frame contains the content carried by one or more T-CONTs.
- All ONUs connected to a GPON port share the upstream bandwidth.
- All ONUs send their data upstream at their own time slots based on bandwidth map (BWmap) requirements.
@@ -195,19 +241,78 @@ layers.
## Configuration Methods[^zyxel]
Several methods are available for the installation and activation of the ONU.
-– Method A: Match serial number and password.
-– Method C: Match PLOAM password or serial number.
-– Method C-autolock: Match serial number.
-– Method D: Volatile auto provision by template.
-– Method E: Non-volatile auto provision by template.
+- Method A: Match serial number and password.
+- Method C: Match PLOAM password or serial number.
+- Method C-autolock: Match serial number.
+- Method D: Volatile auto provision by template.
+- Method E: Non-volatile auto provision by template.
If the ONU is not legal, the ONU registration activation will fail, see [GPON Auth](/gpon-auth) for the ONU States.
+## PLOAM messages[^standardgpon]
+
+PLOAM (Physical Layer OAM) is the message channel between the OLT and the ONU used for the activation, the ranging, the authentication and the encryption keys. The downstream PLOAM messages are carried in the PCBd of every frame, the upstream ones in the PLOAMu field of the burst. The most important messages are:
+
+| Message | Direction | Usage |
+| --------------------- | --------- | ------------------------------------------------------------------------------ |
+| `Upstream_Overhead` | OLT → ONU | preamble, delimiter and pre-assigned delay to use in the upstream bursts (`O2`) |
+| `Serial_Number_ONU` | ONU → OLT | the ONU sends its serial number (vendor ID + vendor specific serial number) (`O3`) |
+| `Assign_ONU-ID` | OLT → ONU | assigns the ONU-ID to the serial number (`O3`) |
+| `Ranging_Time` | OLT → ONU | equalization delay computed with the ranging (`O4`) |
+| `Request_Password` | OLT → ONU | requests the password of the ONU |
+| `Password` | ONU → OLT | the PLOAM password (10 bytes) of the ONU |
+| `Assign_Alloc-ID` | OLT → ONU | assigns the Alloc-IDs of the T-CONTs |
+| `Encrypted_Port-ID` | OLT → ONU | enables or disables the encryption of a GEM port |
+| `Request_Key` | OLT → ONU | requests a new encryption key |
+| `Encryption_Key` | ONU → OLT | the new encryption key, sent in two fragments |
+| `Key_Switching_Time` | OLT → ONU | the frame from which the new key is used |
+| `Deactivate_ONU-ID` | OLT → ONU | deactivates the ONU, which goes back to `O1` |
+| `Disable_Serial_Number` | OLT → ONU | disables (`O7`) or enables again the ONU with the given serial number |
+| `Dying_Gasp` | ONU → OLT | the ONU is losing the power |
+
+The serial number is the identifier of the ONU and the password is the only credential checked at the PLOAM level: this is why on Hack GPON the GPON serial number and the PLOAM password are the first parameters to change when an ONU is replaced. Other credentials, such as the LOID, are checked later through OMCI.
+
+## Security
+
+The security model is very different between GPON and the next generation ITU-T PONs (XG-PON, XGS-PON, NG-PON2), which redesigned it from scratch.
+
+### GPON (G.984.3)[^standardgpon]
+
+- **Encryption**: AES-128 in counter mode, **downstream only**. The upstream is not encrypted, since an ONU cannot receive the upstream of the other ONUs (the splitter only sends it to the OLT). The encryption is enabled per GEM port (unicast GEM ports only, the multicast ones are not encrypted).
+- **Key exchange**: the key is generated by the ONU and sent **in clear** to the OLT in the upstream PLOAM `Encryption_Key` message, requested by `Request_Key` and activated with `Key_Switching_Time`. The security relies on the fact that the upstream cannot be received by the other ONUs.
+- **Authentication**: only the serial number and the PLOAM password, both sent in clear upstream, and optionally the LOID through OMCI. There is no authentication of the OLT and no integrity check of the PLOAM and OMCI messages.
+
+### XG-PON, XGS-PON and NG-PON2 (G.987.3, G.9807.1, G.989.3)[^g987],[^g9807]
+
+- **Encryption**: AES-128 in counter mode in **both directions**: the downstream unicast and broadcast/multicast GEM ports and, optionally, the upstream unicast GEM ports.
+- **Key exchange**: the data encryption keys are generated by the ONU and sent to the OLT **encrypted** with the KEK (Key Encryption Key), using the PLOAM messages `Key_Control` and `Key_Report`; the broadcast keys are distributed through OMCI.
+- **Integrity**: the PLOAM and OMCI messages have a MIC (Message Integrity Check), computed with the integrity keys derived from the master session key.
+- **Authentication**: the serial number and the **Registration ID** (36 bytes, it replaces the 10 bytes GPON password) in the `Registration` PLOAM message. Optionally the ONU and the OLT can authenticate each other (mutual authentication) through OMCI (ME *Enhanced security control*) or IEEE 802.1X, which produces the master session key. Without the mutual authentication, the keys are derived from default values defined by the recommendation, so the encryption and the integrity check still work but the ONU and the OLT are not authenticated.
+
+| Feature | GPON | XG-PON / XGS-PON |
+| ---------------------- | ------------------------------------- | ------------------------------------------------------ |
+| Downstream encryption | AES-128 CTR, unicast GEM ports | AES-128 CTR, unicast and broadcast/multicast GEM ports |
+| Upstream encryption | No | AES-128 CTR, optional, unicast GEM ports |
+| Key transport | in clear, PLOAM upstream | encrypted with the KEK, PLOAM `Key_Report` |
+| Message integrity | No | MIC on PLOAM and OMCI |
+| ONU credential | PLOAM password (10 bytes) | Registration ID (36 bytes) |
+| Mutual authentication | No | Optional (OMCI or IEEE 802.1X) |
+
+## FEC (Forward Error Correction)
+
+| Technology | Downstream FEC | Upstream FEC |
+| ----------------- | ------------------------------------ | ----------------------------------- |
+| GPON | RS(255,239), optional | RS(255,239), optional |
+| XG-PON | RS(248,216), mandatory | RS(248,232), optional |
+| XGS-PON | RS(248,216), mandatory | RS(248,216), optional |
+
+In GPON the FEC is optional and it is enabled by the OLT independently for each direction: the downstream FEC is signalled in the GTC header (the *FEC indication* bit of the PCBd), the upstream FEC is requested by the OLT for each allocation with the *Use FEC* flag of the BWmap. The RS(255,239) code adds 16 parity bytes every 239 data bytes (about 7% of overhead) and corrects up to 8 bytes per codeword, which gives about 3 dB of additional power budget[^standardgpon].
+
## Protocol Stacks[^cisco],[^fs]
-The GPON protocol has its own stack, just Ethernet or IP.
+GPON has its own layer 2 (the GTC sublayer) below Ethernet: the services (data, POTS, video, TDM) are carried over Ethernet/IP or directly over GEM, and everything is framed by the GTC layer over the PON physical layer.
-
+
### Ethernet over GEM[^standardgpon]
@@ -273,15 +378,14 @@ SFU ONUs work under bridging mode (layer 2 of ISO model), support multiple VLAN
[^standardgpon]: *G.984.3: Gigabit-capable passive optical networks (GPON): Transmission convergence layer specification* https://www.itu.int/rec/T-REC-G.984.3
+[^g9842]: *G.984.2: Gigabit-capable passive optical networks (GPON): Physical Media Dependent (PMD) layer specification* https://www.itu.int/rec/T-REC-G.984.2
+[^g987]: *G.987.3: 10-Gigabit-capable passive optical networks (XG-PON): Transmission convergence (TC) layer specification* https://www.itu.int/rec/T-REC-G.987.3
+[^g9807]: *G.9807.1: 10-Gigabit-capable symmetric passive optical network (XGS-PON)* https://www.itu.int/rec/T-REC-G.9807.1
[^fs]: *Comparison of EPON and GPON* https://community.fs.com/blog/comparison-of-epon-and-gpon.html
[^zyxel]: *GPON E2E Fundamentals*, Zyxel 2018
-[^huawei]: *GPON Fundamentals*, Huawei 2010 http://jm.telecoms.free.fr/QCM_Fibre/GPON-Fundamentals_Huawei.pdf
[^broadbandforum]: *GPON in FTTx Broadband Deployments*, Broadband Forum 2010 https://www.broadband-forum.org/download/MR-246.pdf
-[^wolon]: *Fiber SFP Module Compatibility with APC, UPC, PC* https://www.wolonte.com/news.asp?id=599
[^cisco]: *Understand GPON Technology* https://www.cisco.com/c/en/us/support/docs/switches/catalyst-pon-series/216230-understand-gpon-technology.html
[^medium]: *HTFuture: EPON vs GPON Standard* https://medium.com/@ivyhtfuture/epon-vs-gpon-standard-b8ec20c55bb3
-[^telecom]: *Fifty Years of Fixed Optical Networks Evolution: A Survey of Architectural and Technological Developments in a Layered Approach* https://doi.org/10.3390/telecom3040035
-[^huaweimultiplexing]: *GPON Principle---Data Multiplexing* https://forum.huawei.com/enterprise/en/gpon-principle-data-multiplexing/thread/458243-100181
[^huaweiveip]: *VEIP knowledge* https://forum.huawei.com/enterprise/en/veip-knowledge/thread/771975-100181
[^cdatatec]: *Differences between HGU ONU and SFU ONU* https://cdatatec.com/differences-hgu-onu-sfu-onu/
[^arsat]: *Gpon: Tecnology*, ARSAT
diff --git a/ont-epon/CIG_XE-99S.md b/ont-epon/CIG_XE-99S.md
index 1838f530..216ae470 100644
--- a/ont-epon/CIG_XE-99S.md
+++ b/ont-epon/CIG_XE-99S.md
@@ -19,8 +19,7 @@ parent: CIG
| CPU Clock | 125MHz |
| Bootloader | SATURN uboot |
| System | Custom Linux by Cortina (Saturn SDK) based on Kernel 4.4 Saturn-sfpplus-r1 |
-| 2.5GBaseX | Yes |
-| XGMII/XSGMII | Yes |
+| SFP interfaces | 2500BASE-X, 10GBASE-R |
| Optics | SC/UPC |
| IP address | 192.168.0.1 |
| Web Gui | ✅ user `admin`, password `admin` (Custom firmware only) |
diff --git a/ont-epon/LTF7263-BH+.md b/ont-epon/LTF7263-BH+.md
index 40ccaa92..cc43bf64 100644
--- a/ont-epon/LTF7263-BH+.md
+++ b/ont-epon/LTF7263-BH+.md
@@ -19,8 +19,7 @@ parent: HiSense
| CPU Clock | 500MHz |
| Bootloader | SATURN uboot |
| System | Custom Linux by Cortina (Saturn SDK) based on Kernel 4.4 Saturn-sfpplus-r1 |
-| 2.5GBaseX | Yes (Custom firmware only) |
-| XGMII/XSGMII | Yes |
+| SFP interfaces | 2500BASE-X (custom firmware only), 10GBASE-R |
| Optics | SC/UPC |
| IP address | 192.168.0.1 |
| Web Gui | ✅ Oliginal firmware : user `admin`, password `system` / Custom firmware : user `admin`, password `admin` |
diff --git a/ont-epon/free_iliad_F-MDCONU3A.md b/ont-epon/free_iliad_F-MDCONU3A.md
index 09a60dc7..3eede575 100644
--- a/ont-epon/free_iliad_F-MDCONU3A.md
+++ b/ont-epon/free_iliad_F-MDCONU3A.md
@@ -20,7 +20,7 @@ parent: Free/Iliad
| Bootloader | TK2000 Boot v3.27 |
| System | bare-metal (no OS) |
| Load addr | 0x20000000 (ICCM) |
-| HSGMII | No |
+| SFP interfaces | PON RAW (w/o PON MAC, see [SFP with PON MAC and w/o PON MAC](/ont-wo-mac)) |
| Optics | SFP w/o MAC |
| IP address | |
| Web Gui | |
diff --git a/ont-epon/free_iliad_F-MDCONU5A.md b/ont-epon/free_iliad_F-MDCONU5A.md
index db6616fd..b5a88f91 100644
--- a/ont-epon/free_iliad_F-MDCONU5A.md
+++ b/ont-epon/free_iliad_F-MDCONU5A.md
@@ -20,7 +20,7 @@ parent: Free/Iliad
| Bootloader | |
| System | |
| Load addr | |
-| HSGMII | No |
+| SFP interfaces | PON RAW (w/o PON MAC, see [SFP with PON MAC and w/o PON MAC](/ont-wo-mac)) |
| Optics | SFP w/o MAC |
| IP address | |
| Web Gui | |
@@ -29,4 +29,4 @@ parent: Free/Iliad
| Serial | |
| Serial baud | |
| Serial encoding | |
-| Form Factor | ONT |
\ No newline at end of file
+| Form Factor | ONT |
diff --git a/ont-epon/free_iliad_P-MDONU4B.md b/ont-epon/free_iliad_P-MDONU4B.md
index b2b3b0d1..adbe48e4 100644
--- a/ont-epon/free_iliad_P-MDONU4B.md
+++ b/ont-epon/free_iliad_P-MDONU4B.md
@@ -19,8 +19,7 @@ parent: Free/Iliad
| Bootloader | |
| System | |
| Load addr | |
-| XGMII/XSGMII | Yes |
-| 10GBaseX | Yes |
+| SFP interfaces | PON RAW (w/o PON MAC, see [SFP with PON MAC and w/o PON MAC](/ont-wo-mac)) |
| Optics | SFP w/o MAC |
| IP address | |
| Web Gui | |
diff --git a/ont-xgs/ont-fs-XGS-ONU-25-20NI.md b/ont-xgs/ont-fs-XGS-ONU-25-20NI.md
index fcfa10c2..2546e13d 100644
--- a/ont-xgs/ont-fs-XGS-ONU-25-20NI.md
+++ b/ont-xgs/ont-fs-XGS-ONU-25-20NI.md
@@ -20,8 +20,7 @@ parent: FS.com
| CPU Clock | 500MHz |
| Bootloader | SATURN uboot |
| System | Custom Linux by Cortina (Saturn SDK) based on Kernel 4.4 Saturn-sfpplus-r1 |
-| 2.5GBaseX | Yes |
-| XGMII/XSGMII | Yes |
+| SFP interfaces | 2500BASE-X, 10GBASE-R |
| Optics | SC/APC |
| IP address | 192.168.100.1 |
| Web Gui | |
diff --git a/ont-xgs/ont-hisense-ltf7267-bha+.md b/ont-xgs/ont-hisense-ltf7267-bha+.md
index b18a139b..17ba706e 100644
--- a/ont-xgs/ont-hisense-ltf7267-bha+.md
+++ b/ont-xgs/ont-hisense-ltf7267-bha+.md
@@ -15,7 +15,7 @@ parent: HiSense
| Flash | 128MB |
| RAM | 128MB |
| System | Custom Linux by Cortina (Saturn SDK) based on Kernel 4.4 |
-| XGMII/XSGMII | Yes |
+| SFP interfaces | 10GBASE-R |
| Optics | SC/APC |
| IP address | 192.168.0.1 |
| Web Gui | ✅ user `admin`, password `system` |
diff --git a/ont-xgs/ont-nokia-xs-010s-q.md b/ont-xgs/ont-nokia-xs-010s-q.md
index d447e5d0..91a87c84 100644
--- a/ont-xgs/ont-nokia-xs-010s-q.md
+++ b/ont-xgs/ont-nokia-xs-010s-q.md
@@ -20,7 +20,7 @@ parent: Nokia
| Flash | 1GB |
| RAM | ? |
| System | ? |
-| 10GBaseT | Yes |
+| SFP interfaces | 10GBASE-R |
| Optics | SC/APC |
| IP address | 192.168.100.1 |
| Web Gui | ✅ Port 80 user: `admin`, password: `1234` |
diff --git a/ont/ont-avm-g-95sp.md b/ont/ont-avm-g-95sp.md
index 537c46a0..48ff9b99 100644
--- a/ont/ont-avm-g-95sp.md
+++ b/ont/ont-avm-g-95sp.md
@@ -18,7 +18,7 @@ parent: AVM
| Flash | |
| RAM | |
| System | Linux (kernel 3.10.4, AVM firmware `SFP_7.5.13`) |
-| HSGMII | No (SGMII / 1000Base-X) |
+| SFP interfaces | SGMII, 1000BASE-X |
| Optics | SC/APC |
| IP address | 192.168.47.1 |
| Web Gui | No |
diff --git a/ont/ont-carlitoxxpro-cpgos03-0490-v2.md b/ont/ont-carlitoxxpro-cpgos03-0490-v2.md
index 32e790b4..ceab725e 100644
--- a/ont/ont-carlitoxxpro-cpgos03-0490-v2.md
+++ b/ont/ont-carlitoxxpro-cpgos03-0490-v2.md
@@ -14,7 +14,7 @@ parent: CarlitoxxPro
| Flash | 8 MB |
| RAM | 64 MB |
| System | Linux (Luna SDK) |
-| HSGMII | No |
+| SFP interfaces | 1 Gbps only, no HSGMII |
| Optics | SC/APC |
| IP address | |
| Web Gui | ✅ user `cpAdmin`, password `cpAdmin` |
diff --git a/ont/ont-cig-g-95sp.md b/ont/ont-cig-g-95sp.md
index 3cdc1f45..6bfe4def 100644
--- a/ont/ont-cig-g-95sp.md
+++ b/ont/ont-cig-g-95sp.md
@@ -17,7 +17,7 @@ parent: CIG
| Flash | |
| RAM | |
| System | |
-| HSGMII | No (SGMII / 1000Base-X) |
+| SFP interfaces | SGMII, 1000BASE-X |
| Optics | SC/APC |
| IP address | |
| Web Gui | |
diff --git a/ont/ont-cig-g-97sp.md b/ont/ont-cig-g-97sp.md
index 2690c20b..0b8bec4b 100644
--- a/ont/ont-cig-g-97sp.md
+++ b/ont/ont-cig-g-97sp.md
@@ -16,7 +16,7 @@ parent: CIG
| CPU Clock | |
| Flash | |
| RAM | |
-| HSGMII | |
+| SFP interfaces | |
| Optics | SC |
| IP address | |
| Web Gui | |
diff --git a/ont/ont-d-link-dpn-100-rev-a2.md b/ont/ont-d-link-dpn-100-rev-a2.md
index d1665211..067fd2d2 100644
--- a/ont/ont-d-link-dpn-100-rev-a2.md
+++ b/ont/ont-d-link-dpn-100-rev-a2.md
@@ -16,7 +16,7 @@ parent: D-LINK
| Flash | 8 MB |
| RAM | 64 MB |
| System | |
-| HSGMII | |
+| SFP interfaces | |
| Optics | |
| IP address | |
| Web Gui | |
diff --git a/ont/ont-d-link-dpn-100-rev-c1.md b/ont/ont-d-link-dpn-100-rev-c1.md
index d02d1eea..c9ec30cd 100644
--- a/ont/ont-d-link-dpn-100-rev-c1.md
+++ b/ont/ont-d-link-dpn-100-rev-c1.md
@@ -16,7 +16,7 @@ parent: D-LINK
| Flash | 16MB |
| RAM | 32MB |
| System | Linux (Luna SDK 1.9.0) |
-| HSGMII | ✅ |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | 192.168.100.1 |
| Web Gui | |
diff --git a/ont/ont-fibermall-gpon-onu-stb+.md b/ont/ont-fibermall-gpon-onu-stb+.md
index 065d6dc9..16f41687 100644
--- a/ont/ont-fibermall-gpon-onu-stb+.md
+++ b/ont/ont-fibermall-gpon-onu-stb+.md
@@ -18,7 +18,7 @@ This is an ONU Stick SFP with integrated GPON MAC. For the raw SFP transceiver w
| Flash | |
| RAM | |
| System | |
-| HSGMII | |
+| SFP interfaces | |
| Optics | SC/UPC or SC/APC |
| IP address | |
| Web Gui | |
diff --git a/ont/ont-fs-com-gpon-onu-stick-with-mac.md b/ont/ont-fs-com-gpon-onu-stick-with-mac.md
index d4b3ee5f..f1b172ef 100644
--- a/ont/ont-fs-com-gpon-onu-stick-with-mac.md
+++ b/ont/ont-fs-com-gpon-onu-stick-with-mac.md
@@ -21,7 +21,7 @@ parent: FS.com
| Bootloader | U-Boot 2011.12-lantiq-gpon-1.2.24 |
| System | OpenWRT 14.07_ltq (Kernel 3.10.49) |
| Load addr | 0x80800000 |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | 192.168.1.10 |
| Web Gui | |
diff --git a/ont/ont-halny-hl-gsfp.md b/ont/ont-halny-hl-gsfp.md
index 02e3c948..2d64fc00 100644
--- a/ont/ont-halny-hl-gsfp.md
+++ b/ont/ont-halny-hl-gsfp.md
@@ -18,7 +18,7 @@ parent: HALNy
| CPU | MIPS 34Kc interAptiv |
| CPU Clock | 400MHz |
| System | OpenWRT |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | 192.168.77.154/30 |
| Web Gui | none |
diff --git a/ont/ont-hilink-hl23446.md b/ont/ont-hilink-hl23446.md
index 652eb336..b25e5681 100644
--- a/ont/ont-hilink-hl23446.md
+++ b/ont/ont-hilink-hl23446.md
@@ -17,7 +17,7 @@ parent: Hilink
| CPU | MIPS 34Kc interAptiv |
| CPU Clock | 400MHz |
| System | OpenWRT |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | |
| Web Gui | ✅ |
diff --git a/ont/ont-huawei-ma5671a.md b/ont/ont-huawei-ma5671a.md
index 2db63198..e25eb827 100644
--- a/ont/ont-huawei-ma5671a.md
+++ b/ont/ont-huawei-ma5671a.md
@@ -17,7 +17,7 @@ parent: Huawei
| CPU | MIPS 34Kc interAptiv |
| CPU Clock | 400MHz |
| System | OpenWRT |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | 192.168.1.10 |
| Web Gui | After root |
diff --git a/ont/ont-huawei-optixstar-s600e.md b/ont/ont-huawei-optixstar-s600e.md
index 86c8dd72..924d1531 100644
--- a/ont/ont-huawei-optixstar-s600e.md
+++ b/ont/ont-huawei-optixstar-s600e.md
@@ -16,7 +16,7 @@ parent: Huawei
| Flash | |
| RAM | |
| System | |
-| HSGMII | |
+| SFP interfaces | |
| Host interface | GE/2.5GE/5GE/10GE adaptive (per Huawei) |
| Optics | SC/APC |
| IP address | |
diff --git a/ont/ont-leox-lxt-010s-h.md b/ont/ont-leox-lxt-010s-h.md
index 98c15f1c..0a2bc207 100644
--- a/ont/ont-leox-lxt-010s-h.md
+++ b/ont/ont-leox-lxt-010s-h.md
@@ -16,7 +16,7 @@ parent: LEOX
| Flash | 128MB |
| RAM | 32MB |
| System | Linux 3.18 (Luna SDK 3.3) |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/UPC or SC/APC |
| IP address | 192.168.100.1/24 |
| Web Gui | ✅ |
diff --git a/ont/ont-nokia-g-010s-a.md b/ont/ont-nokia-g-010s-a.md
index f78db290..cb5782f5 100644
--- a/ont/ont-nokia-g-010s-a.md
+++ b/ont/ont-nokia-g-010s-a.md
@@ -17,7 +17,7 @@ parent: Nokia
| CPU | MIPS 34Kc interAptiv |
| CPU Clock | 400MHz |
| System | OpenWRT |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/UPC |
| IP address | 192.168.1.10 |
| Web Gui | ✅ user `adminadmin`, password `ALC#FGU` |
diff --git a/ont/ont-nokia-g-010s-b.md b/ont/ont-nokia-g-010s-b.md
index 7ae3cd8a..d7f87573 100644
--- a/ont/ont-nokia-g-010s-b.md
+++ b/ont/ont-nokia-g-010s-b.md
@@ -18,7 +18,7 @@ parent: Nokia
| Flash | 16 MB (Macronix MX25L25635FZ2R-10G) |
| RAM | 64 MB (Winbond W9751G6KB-25I) |
| System | OpenWRT |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/UPC |
| IP address | 192.168.1.10 |
| Web Gui | ✅ user `adminadmin`, password `ALC#FGU` |
diff --git a/ont/ont-nokia-g-010s-p.md b/ont/ont-nokia-g-010s-p.md
index 1db6e1c5..4a1c3545 100644
--- a/ont/ont-nokia-g-010s-p.md
+++ b/ont/ont-nokia-g-010s-p.md
@@ -18,7 +18,7 @@ parent: Nokia
| CPU | MIPS 34Kc interAptiv |
| CPU Clock | 400MHz |
| System | OpenWRT |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | 192.168.1.10 |
| Web Gui | Can be enabled |
diff --git a/ont/ont-nokia-g-010s-q.md b/ont/ont-nokia-g-010s-q.md
index da8d4a35..5dee296c 100644
--- a/ont/ont-nokia-g-010s-q.md
+++ b/ont/ont-nokia-g-010s-q.md
@@ -17,7 +17,7 @@ alias: CIG G-97S
| Flash | 16 MB (Macronix MX25L12835F) |
| RAM | 32 MB |
| System | |
-| HSGMII | |
+| SFP interfaces | |
| Optics | |
| IP address | 192.168.100.1 |
| Web Gui | ✅ Port 80 (⚠️ *only available when the PON connection **IS NOT** estabilished*), user `admin`, password `1234` |
diff --git a/ont/ont-odi-realtek-dfp-34g-2c2.md b/ont/ont-odi-realtek-dfp-34g-2c2.md
index d5bc1ce7..47766cfa 100644
--- a/ont/ont-odi-realtek-dfp-34g-2c2.md
+++ b/ont/ont-odi-realtek-dfp-34g-2c2.md
@@ -15,7 +15,7 @@ parent: ODI
| Flash | 8 MB |
| RAM | 64 MB |
| System | Linux (Luna SDK 1.9) |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/UPC |
| IP address | 192.168.1.1 |
| Web Gui | ✅ user `admin`, password `admin` |
diff --git a/ont/ont-odi-realtek-dfp-34x-2c2.md b/ont/ont-odi-realtek-dfp-34x-2c2.md
index e9d2d7f2..1e73b465 100644
--- a/ont/ont-odi-realtek-dfp-34x-2c2.md
+++ b/ont/ont-odi-realtek-dfp-34x-2c2.md
@@ -15,7 +15,7 @@ parent: ODI
| Flash | 8 MB |
| RAM | 64 MB |
| System | Linux (Luna SDK 1.9) |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/UPC(DFP-34X-2C2), SC/APC(DFP-34X-2C3)|
| IP address | 192.168.1.1 |
| Web Gui | ✅ user `admin`, password `admin` |
diff --git a/ont/ont-odi-zte-dfp-34g-2c2.md b/ont/ont-odi-zte-dfp-34g-2c2.md
index fa4137c3..98bc4549 100644
--- a/ont/ont-odi-zte-dfp-34g-2c2.md
+++ b/ont/ont-odi-zte-dfp-34g-2c2.md
@@ -17,7 +17,7 @@ alias: Usourcetech UGP-N1S
| Flash | 16 MB |
| RAM | 32 MB |
| System | System ZTE Linux (based on Linux Kernel 2.6.32) |
-| HSGMII | No |
+| SFP interfaces | 1 Gbps only, no HSGMII |
| Optics | SC/UPC |
| IP address | 192.168.1.1 |
| Web Gui | ✅ user `admin`, password `admin` |
diff --git a/ont/ont-sercomm-fgs202.md b/ont/ont-sercomm-fgs202.md
index e676eb97..e04a9690 100644
--- a/ont/ont-sercomm-fgs202.md
+++ b/ont/ont-sercomm-fgs202.md
@@ -14,7 +14,7 @@ parent: Sercomm
| Flash | 8 MiB (MXIC MX25L6405D) |
| RAM | 1 MiB |
| System | eCos |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | 192.168.2.200/24 |
| Web Gui | No |
diff --git a/ont/ont-sourcephotonics-sps-34-24t-hp-tdfm.md b/ont/ont-sourcephotonics-sps-34-24t-hp-tdfm.md
index f0c248df..dd11608f 100644
--- a/ont/ont-sourcephotonics-sps-34-24t-hp-tdfm.md
+++ b/ont/ont-sourcephotonics-sps-34-24t-hp-tdfm.md
@@ -20,7 +20,7 @@ parent: SourcePhotonics
| System | |
| Serial baud | |
| Load addr | |
-| HSGMII | |
+| SFP interfaces | |
| Optics | SC |
| IP address | |
| Web Gui | |
@@ -31,4 +31,4 @@ parent: SourcePhotonics
# Miscellaneous Links
-- [SourcePhotonics SPS-34-24T-HP-TDFM Datasheet](/assets/pdf/SPS-34-24T-HP-TDFM.pdf)
\ No newline at end of file
+- [SourcePhotonics SPS-34-24T-HP-TDFM Datasheet](/assets/pdf/SPS-34-24T-HP-TDFM.pdf)
diff --git a/ont/ont-t-w-twcgpon657.md b/ont/ont-t-w-twcgpon657.md
index 1a13ae1b..f67670d5 100644
--- a/ont/ont-t-w-twcgpon657.md
+++ b/ont/ont-t-w-twcgpon657.md
@@ -15,7 +15,7 @@ parent: T&W
| Flash | 16 MB |
| RAM | 64 MB |
| System | Linux (Luna SDK) |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | |
| Web Gui | ✅ user `admin`, password `system` |
diff --git a/ont/ont-technicolor-afm0002.md b/ont/ont-technicolor-afm0002.md
index 22372170..f7f770bb 100644
--- a/ont/ont-technicolor-afm0002.md
+++ b/ont/ont-technicolor-afm0002.md
@@ -17,7 +17,7 @@ alias: HiSense LTE3415-SCA+
| Flash | 32MB |
| RAM | 16MB |
| System | Linux (Luna SDK 1.9) |
-| HSGMII | No |
+| SFP interfaces | 1 Gbps only, no HSGMII |
| Optics | SC/APC |
| IP address | 192.168.2.1 / 169.0.0.1 |
| Web Gui | Can be enabled, user `admin`, password `system` |
diff --git a/ont/ont-technicolor-afm0003.md b/ont/ont-technicolor-afm0003.md
index d59335a2..d0655dcf 100644
--- a/ont/ont-technicolor-afm0003.md
+++ b/ont/ont-technicolor-afm0003.md
@@ -17,7 +17,7 @@ alias: HiSense LTE3415-SH+
| Flash | 128MB |
| RAM | 32MB |
| System | Linux 2.6 (Luna SDK 1.9) |
-| HSGMII | Yes, but not working with stock firmware |
+| SFP interfaces | HSGMII (not working with stock firmware) |
| Optics | SC/APC |
| IP address | 192.168.2.1 |
| Web Gui | Can be enabled, user `admin`, password `system` |
diff --git a/ont/ont-template.md b/ont/ont-template.md
index 27e25a1e..212e9a85 100644
--- a/ont/ont-template.md
+++ b/ont/ont-template.md
@@ -14,11 +14,8 @@
| Bootloader | |
| System | |
| Load addr | |
-| HSGMII | Yes/No (only if miniONT SFP PHY) |
-| 2.5GBaseX | Yes/No (only if miniONT SFP MAC) |
+| SFP interfaces | e.g. SGMII, 1000BASE-X, HSGMII, 2500BASE-X, 10GBASE-R, see [SFP standard](/sfp-standard#interfaces-table) (only if miniONT SFP) |
| 2.5GBaseT | Yes/No (only if ONT) |
-| XGMII/XSGMII | Yes (only if miniONT SFP PHY) |
-| 10GBaseX | Yes/No (only if miniONT SFP MAC) |
| 10GBaseT | Yes/No (only if ONT) |
| 2.5/5/10GBaseT | Yes/No (only if ONT multigig) |
| Optics | SC/APC or SC/UPC |
diff --git a/ont/ont-ufiber-uf-instant.md b/ont/ont-ufiber-uf-instant.md
index f8169425..c3386956 100644
--- a/ont/ont-ufiber-uf-instant.md
+++ b/ont/ont-ufiber-uf-instant.md
@@ -14,7 +14,7 @@ parent: UFiber
| Flash | 16 MB |
| RAM | 64 MB |
| System | Linux (Luna SDK) |
-| HSGMII | No |
+| SFP interfaces | 1 Gbps only, no HSGMII |
| Optics | SC/APC |
| IP address | |
| Web Gui | ✅ |
diff --git a/ont/ont-vsol-v2801f.md b/ont/ont-vsol-v2801f.md
index db61718e..185edf3b 100644
--- a/ont/ont-vsol-v2801f.md
+++ b/ont/ont-vsol-v2801f.md
@@ -14,7 +14,7 @@ parent: V-SOL
| Flash | 8 MB |
| RAM | 64 MB |
| System | Linux (Luna SDK) |
-| HSGMII | No |
+| SFP interfaces | 1 Gbps only, no HSGMII |
| Optics | SC/APC |
| IP address | |
| Web Gui | ✅ user `admin`, password `stdONU101` |
diff --git a/ont/ont-zisa-op151s.md b/ont/ont-zisa-op151s.md
index ea9557ff..79ee2b1f 100644
--- a/ont/ont-zisa-op151s.md
+++ b/ont/ont-zisa-op151s.md
@@ -19,7 +19,7 @@ parent: Zisa
| Flash | 8 MB (GigaDevice GD25Q64CW16) |
| RAM | 64 MB (Nanya NT5TU32M16FG-AC1) |
| System | eCoS |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | 10.10.1.1 |
| Web Gui | ✅ username `admin` or `guest`, password `1234` or `guest` |
@@ -51,4 +51,4 @@ Some USB TTL adapters label TX and RX pins the other way around: try to swap the
# Miscellaneous Links
- [Tech Info Depot Wiki](http://en.techinfodepot.shoutwiki.com/wiki/ZISA_OP151S)
-- [Zisa OP151S 1GE GPON SFU SFP module](https://www.zisacom.com/admin/ewebeditor/uploadfile/20181116154842842.pdf)
\ No newline at end of file
+- [Zisa OP151S 1GE GPON SFU SFP module](https://www.zisacom.com/admin/ewebeditor/uploadfile/20181116154842842.pdf)
diff --git a/ont/ont-zyxel-pmg3000-d20b.md b/ont/ont-zyxel-pmg3000-d20b.md
index 326c0a1c..b4d01b5f 100644
--- a/ont/ont-zyxel-pmg3000-d20b.md
+++ b/ont/ont-zyxel-pmg3000-d20b.md
@@ -18,7 +18,7 @@ parent: Zyxel
| CPU | MIPS 34Kc interAptiv |
| CPU Clock | 400MHz |
| System | eCoS |
-| HSGMII | Yes |
+| SFP interfaces | HSGMII |
| Optics | SC/APC |
| IP address | 10.10.1.1 |
| Web Gui | ✅ username `admin` or `guest`, password `1234` or `guest` |
diff --git a/sfp/sfp-standard.md b/sfp/sfp-standard.md
index 2bbf45de..57422572 100644
--- a/sfp/sfp-standard.md
+++ b/sfp/sfp-standard.md
@@ -9,23 +9,112 @@ The organisation that developed SFPs (MSA SFP) has always been very cautious abo
After the SFP standard entered the market, in the early 2000s with Ethernet and Fibre Channel, the MSA SFP also started standardising signalling, starting with [^sfprate] and [^sfprate2] which define a list of admissible standard signalling limited to the capabilities of the current form factor SFP.
With the need to increase the heat dissipation characteristics of the modules (in order to increase speeds) and to allow some additions to the EEPROM, an additional standard, called SFP+[^sfpplusstandard],[^sfpplusmi],[^xenpak_xfp], was developed, which contains all the aforementioned improvements. The 16GFC, 20GFC signalling for Fibre Channel and the 10 Gbps and 2.5 signalling for Ethernet were also included in the updated [^sfprate] and [^sfprate2] standard. Some of these are also included in [^sfpplusstandard] locking the SFP+ standard to a tenth of signalling, all other signals should fall under the SFP standard[^sfpstandard], but they can use the extended SFP+ management interface[^sfpplusmi].
-The Ethernet signals are all very similar, but there are some differences between Base-X and MII. The media-independent interface (MII) was defined in the IEEE 802.11u standard. It was originally defined as a standard interface to connect a Fast Ethernet MAC block (i.e. CPU, switch) to a PHY chip (i.e. twisted pair, fiber optic, etc.) in a standardised way. The main advantage is that MII can be used without redesigning or replacing the MAC hardware. Thus any MAC may be used with any PHY, independent of the network signal transmission media[^ethernet].
+# Ethernet over the SFP: MII and Base-X
-The main difference is the physical media over which the frames are:
-- *Base-X* is based on the Ethernet PHYsical Layer (layer 1) and this standard uses the 8B/10B coding (or other encodings as specified in the EEPROM), and *MII* is based on the Ethernet MAC Device (layer 2, the device that actually makes and receives Ethernet frames)[^ethernet].
-- In *Base-X*, auto-negotiation is limited to flow-control (and duplex, which is not really used since it's always full-duplex), and in *MII*, auto-negotiation (AN) also allows the PHY to indicate to the MAC the post-PHY link speed. Even though the MAC-to-PHY SGMII link is always 1000Mbps, it supports 10, 100 and 1000Mbps past the PHY and the MAC needs to know this to space out the bits properly (e. g. if the external link is 100Mbps, each bit on the SGMII link is sent 10 times)[^ethernet].
+The Ethernet signals carried on the SFP pins are all very similar, but there are some important differences between the *Base-X* interfaces and the *MII* family. The media-independent interface (MII) was defined in the IEEE 802.3u standard. It was originally defined as a standard interface to connect a Fast Ethernet MAC block (i.e. CPU, switch) to a PHY chip (i.e. twisted pair, fiber optic, etc.) in a standardised way. The main advantage is that MII can be used without redesigning or replacing the MAC hardware. Thus any MAC may be used with any PHY, independent of the network signal transmission media[^ethernet].
+
+The main differences are:
+- *Base-X* is an Ethernet PHYsical layer (layer 1) standard: it describes the signal on the medium (fiber, twinax copper) and it uses the 8B/10B coding (or other encodings, such as 64B/66B for 10GBASE-R, as specified in the EEPROM). *MII* is the interface towards the Ethernet MAC device (layer 2, the device that actually makes and receives Ethernet frames)[^ethernet].
+- *Base-X* is **symmetric**: both ends of the link are equal and the auto-negotiation (IEEE 802.3 Clause 37) only exchanges the duplex and flow-control (pause) abilities, the speed is fixed. *SGMII* is **asymmetric**: one end is the *PHY side* and the other one is the *MAC side*. The PHY side sends to the MAC side the link status, the speed and the duplex of the medium past the PHY, the MAC side only acknowledges them. Even though the MAC-to-PHY SGMII link is always 1.25 GBd, it supports 10, 100 and 1000 Mbps past the PHY and the MAC needs to know this to space out the bits properly (e.g. if the external link is 100 Mbps, each bit on the SGMII link is sent 10 times)[^sgmii].
MII can be used to connect a MAC to an external PHY using a pluggable connector, or directly to a PHY chip on the same PCB. In the first case it is also used in SFP connectors, for example to allow connections between two MAC blocks without passing through a PHY (i.e. passive DAC).
-This technology, and in particular its evolutions such as RGMII[^rgmii], SGMII[^sgmii], QSGMII[^qsgmii], XGMII[^intel], USXGMII[^xilinx], is widely used as a communication bus over SFP, in addition to IEEE BaseX[^ethernet]. The 2.5G-SGMII or HSGMII[^altium] and 10G-SGMII or XSGMII[^aquantia] standards are specifics that increase the clock speed of the SGMII standard without redefining it.
+This technology, and in particular its evolutions such as RGMII[^rgmii], SGMII[^sgmii], QSGMII[^qsgmii], XGMII[^intel], USXGMII[^xilinx], is widely used as a communication bus, while on the SFP pins only the serial ones (SGMII, USXGMII and their overclocked variants) can be used, in addition to the IEEE Base-X[^ethernet]. The 2.5G-SGMII or HSGMII[^altium] and 10G-SGMII or XSGMII[^aquantia] are vendor specific interfaces that increase the clock speed of the SGMII standard without redefining it.
+
+## PHY mode, MAC mode and Base-X
+
+Since SGMII is asymmetric, a device that speaks SGMII must know which side it is. Many ONT sticks (e.g. the Realtek based ones, see `sgmii_mode` or `LAN_SDS_MODE` in the device pages) can be configured in all these modes:
+
+- **SGMII/HSGMII PHY mode**: the stick behaves like a copper SFP with a PHY inside: it is the PHY side and the host (router, switch, NIC) is the MAC side. This is the mode expected by a host that supports SGMII, and it is the same mode used by the 1000BASE-T copper SFPs, which have a PHY (e.g. Marvell 88E1111) behind the SFP pins.
+- **SGMII/HSGMII MAC mode**: the stick behaves like a MAC, so it must be connected to a PHY (e.g. a media converter with an Ethernet PHY between the SFP cage and the RJ45 port). Two devices in MAC mode do not link, since nobody sends the link information.
+- **Base-X mode** (1000BASE-X, 2500BASE-X): the stick behaves like an optical transceiver: there is no PHY side or MAC side, the speed is fixed and only duplex and pause are negotiated (or the negotiation is disabled).
+
+```mermaid
+graph LR
+ subgraph A[SGMII PHY mode]
+ A1[Host MAC] <-->|SGMII, AN: link/speed/duplex sent by the stick| A2[ONT stick as PHY]
+ end
+ subgraph B[SGMII MAC mode]
+ B1[ONT stick as MAC] <-->|SGMII, AN: link/speed/duplex sent by the PHY| B2[Media converter PHY]
+ B2 <--> B3[RJ45]
+ end
+ subgraph C[Base-X mode]
+ C1[Host PCS] <-->|1000BASE-X / 2500BASE-X, AN: duplex/pause only| C2[ONT stick PCS]
+ end
+```
+
+The modes are not interchangeable: an SGMII host with the in-band auto-negotiation enabled does not link with a stick in Base-X mode and vice versa, even if the line rate and the encoding are the same. When the auto-negotiation is disabled on both sides, an SGMII link at 1 Gbps and a 1000BASE-X link look the same on the wire, and this is why many devices work in both cases.
+
+## The Linux kernel point of view
+
+The Linux kernel (phylink and the SFP subsystem) models exactly these interfaces, and it is a good reference for how a host chooses the mode[^linux-phylink]:
+
+- the interface between the MAC and the SFP is described by the `phy-mode` (`phy_interface_t`) property in the device tree, for example `sgmii`, `1000base-x`, `2500base-x`, `5gbase-r`, `10gbase-r`, `usxgmii`; `xgmii` and `rgmii` exist too, but they are parallel interfaces used on the PCB and never on the SFP pins;
+- the in-band auto-negotiation is enabled with `managed = "in-band-status"`, otherwise the link is forced (`fixed-link`);
+- when a module is inserted, `sfp_parse_support()` (in `drivers/net/phy/sfp-bus.c`) reads the EEPROM compliance codes and builds the list of the supported link modes and interfaces; if no compliance code is set it uses the nominal signaling rate: a module between 1.2 and 1.3 GBd is treated as `1000base-x`, a module between 2.5 and 3.2 GBd is treated as `2500base-x`[^linux-sfpbus];
+- when the module contains a PHY (e.g. a 1000BASE-T copper SFP with the PHY on the I2C address `0x56`), the kernel probes it and uses `sgmii` with the module as the PHY side;
+- the modules that declare wrong values in the EEPROM are fixed with quirks in `drivers/net/phy/sfp.c`, for example the [Nokia G-010S-P](/ont-nokia-g-010s-p) (`ALCATELLUCENT G010SP`) and the [Huawei MA5671A](/ont-huawei-ma5671a) (`HUAWEI MA5671A`) are forced to `2500base-x`[^linux-sfp].
+
+The EEPROM content of a module can be read with `ethtool -m `.
+
+# Interfaces table
+
+The following table lists the interfaces used on the SFP pins, with the values that a module should declare in the SFF-8472 EEPROM (address `0xA0`)[^sfpplusmi],[^sff8024]:
+
+- **Compliance**: transceiver compliance codes, byte 3 (10G Ethernet), byte 6 (Ethernet) or byte 36 (extended compliance codes, SFF-8024);
+- **Encoding**: byte 11 (`01h` 8B/10B, `02h` 4B/5B, `06h` 64B/66B);
+- **BR, Nominal**: byte 12, nominal signaling rate in units of 100 MBd;
+- **Rate identifier**: byte 13, it is used for the rate select of the Fibre Channel modules, it is `00h` (unspecified) for the Ethernet modules.
+
+| Interface | Standard | Data rate | Signaling rate | Encoding | In-band auto-negotiation | Compliance (SFF-8472/8024) | Encoding | BR, Nominal | Linux `phy-mode` |
+| ----------------------- | ------------------------------------------------- | ----------------------- | -------------------------- | -------- | ----------------------------------------- | --------------------------------------------------------------------------------------------- | -------- | ----------- | ------------------------------------------ |
+| 100BASE-FX | IEEE 802.3 Clause 24/26 | 100 Mbps | 125 MBd | 4B/5B | No | byte 6 bit 5 (100BASE-FX), bit 4 (100BASE-LX/LX10) | `02h` | `01h` | `100base-x` |
+| SGMII | Cisco ENG-46158[^sgmii] | 10/100/1000 Mbps | 1.25 GBd | 8B/10B | Yes, link/speed/duplex from the PHY side | none, the copper SFPs declare byte 6 bit 3 (1000BASE-T) | `01h` | `0Ch`/`0Dh` | `sgmii` |
+| 1000BASE-X | IEEE 802.3 Clause 36/37 | 1000 Mbps | 1.25 GBd | 8B/10B | Yes, duplex/pause (Clause 37) | byte 6 bit 0 (SX), 1 (LX), 2 (CX), 6 (BX10), 7 (PX) | `01h` | `0Ch`/`0Dh` | `1000base-x` |
+| HSGMII (2.5G-SGMII) | vendor specific[^altium] | 2500 Mbps | 3.125 GBd[^rtl960x] | 8B/10B | Vendor specific, usually disabled | none | `01h` | `1Fh` | none, `2500base-x` with AN disabled |
+| 2500BASE-X | industry naming of the IEEE 802.3cb 2.5GBASE-X PCS | 2500 Mbps | 3.125 GBd | 8B/10B | Clause 37 like, usually disabled | none, it is detected by the nominal rate | `01h` | `1Fh` | `2500base-x` |
+| 2.5GBASE-T (copper SFP) | IEEE 802.3bz | 2500 Mbps on the RJ45 | 3.125 GBd on the SFP pins | 8B/10B | Depends on the PHY inside the module | byte 36 `1Eh` | `01h` | `1Fh` | `2500base-x`, or `sgmii` with rate matching |
+| 5GBASE-R | IEEE 802.3cb (5GBASE-KR PCS) | 5000 Mbps | 5.15625 GBd | 64B/66B | No | byte 36 `1Dh` (5GBASE-T copper SFP) | `06h` | `33h`/`34h` | `5gbase-r` |
+| 10GBASE-R (SFI) | IEEE 802.3 Clause 49, SFF-8431[^sfpplusstandard] | 10 Gbps | 10.3125 GBd | 64B/66B | No | byte 3 bit 4 (SR), 5 (LR), 6 (LRM), 7 (ER); byte 36 `16h` or `1Ch` for the 10GBASE-T copper SFP+ | `06h` | `67h` | `10gbase-r` |
+| XSGMII (10G-SGMII) | vendor specific[^aquantia] | 10 Gbps | 10.3125 GBd | 64B/66B | Vendor specific | none | `06h` | `67h` | none |
+| USXGMII | Cisco/Xilinx[^xilinx] | 10M/100M/1G/2.5G/5G/10G | 10.3125 GBd | 64B/66B | Yes, link/speed/duplex from the PHY side | none | `06h` | `67h` | `usxgmii` |
+
+Some notes on the table:
+
+- there is no compliance code for SGMII, HSGMII and the other MII interfaces: the EEPROM can only declare the medium (e.g. 1000BASE-T, 1000BASE-LX) and the nominal signaling rate, the MII mode is a convention between the host and the module;
+- HSGMII and 2500BASE-X have the same line rate (3.125 GBd, which carries 2.5 Gbps with the 8B/10B coding) and the same coding, the only difference is the in-band auto-negotiation: for this reason a stick in HSGMII mode works on most 2500BASE-X hosts when the auto-negotiation is disabled[^rtl960x];
+- some ONT sticks declare a nominal rate lower than 3.125 GBd (e.g. `19h`, 2.5 GBd) or a 1000BASE-X compliance code even if they work at 2.5 Gbps, this is why a host may need a quirk or a manual setting to use them at 2.5 Gbps;
+- the BR, Nominal values are typical values: the unit is 100 MBd, so 1.25 GBd can be rounded to `0Ch` (1.2 GBd) or `0Dh` (1.3 GBd).
+
+## 1000BASE-X variants
+
+All these variants use 8B/10B at 1.25 GBd and they are seen by the host as 1000BASE-X, they only differ on the optical side[^ethernet],[^wiki-gbe]:
+
+| Variant | Medium | Wavelength | Typical reach | SFF-8472 byte 6 |
+| ------------- | -------------------------------- | -------------------------------- | ------------- | --------------- |
+| 1000BASE-SX | Multi-mode fiber | 850 nm | 220 - 550 m | bit 0 |
+| 1000BASE-LX | Single-mode or multi-mode fiber | 1310 nm | 5 km (SMF) | bit 1 |
+| 1000BASE-LX10 | Single-mode fiber | 1310 nm | 10 km | bit 1 |
+| 1000BASE-BX10 | Single-mode fiber, single strand | 1310 nm / 1490 nm (or 1550 nm) | 10 km | bit 6 |
+| 1000BASE-EX | Single-mode fiber (not IEEE) | 1310 nm | 40 km | none |
+| 1000BASE-ZX | Single-mode fiber (not IEEE) | 1550 nm | 70 km | none |
+| 1000BASE-PX | Single-mode fiber, EPON | 1490 nm / 1310 nm | 10 - 20 km | bit 7 |
+| 1000BASE-CX | Twinax copper | - | 25 m | bit 2 |
+| 1000BASE-T | Twisted pair (module with a PHY) | - | 100 m | bit 3 |
+
+Note that 1000BASE-PX is the 1G-EPON optical interface (see [EPON](/epon-standard)): in this case the SFP is an OLT or ONU transceiver and the 1.25 GBd signal is the PON signal itself, not an Ethernet link towards the host.
+
+# How the interfaces are reported on Hack GPON
+
+The ONT stick pages report the host interfaces supported by the stick in the **SFP interfaces** row of the hardware specifications table, using the names of the table above, e.g. `SGMII, 1000BASE-X, HSGMII, 2500BASE-X`. The ONT pages report the Ethernet ports (e.g. `2.5GBaseT`), the router pages report the interfaces supported by the SFP cage in the *SFP* row, and the SFP cage pages report the interfaces supported by the host. The sticks without a PON MAC do not use any of these interfaces, see [SFP with PON MAC and w/o PON MAC](/ont-wo-mac).
-RGMII, SGMII, 1000BaseX standards allow a speed of 1 Gbps, 2.5BaseX and HSGMII standards of 2.5 Gbps, the XGMII, XSGMII, USXGMII and 10GBaseT of 10 Gbps.
+RGMII, SGMII and 1000BASE-X allow a speed of 1 Gbps, 2500BASE-X and HSGMII of 2.5 Gbps, 5GBASE-R of 5 Gbps, 10GBASE-R, XSGMII and USXGMII of 10 Gbps.
---
[^xenpak_xfp]: With the advent of higher speeds MSA has developed several new interfaces, such as XENPAK, X2, XPAK, XFP, but the newest standard is the transceiver is called SFP+. Based on the same form factor as SFP, it is smaller than its predecessors and has lower power than XFP. SFP+ has become the most popular socket on 10GbE systems because it shares a common physical form factor with legacy SFP modules, allowing higher port density than XFP and the reuse of existing designs for 24 or 48 ports in a 19-inch rack width blade.
[^sfpstandard]: *Specification for SFP (Small Formfactor Pluggable) Transceiver* INF-8074
[^sfprate]: *SFP Rate and Application Selection* SFF-8079
[^sfprate2]: *SFP (Small Formfactor Pluggable) Rate and Application Codes* SFF-8089
-[^sfpplusmi]: *Management Interface for SFP+* SFF-8472
+[^sfpplusmi]: *Management Interface for SFP+* SFF-8472 Rev 12.4 https://members.snia.org/document/dl/26895
[^sfpplusstandard]: *Enhanced Small Form Factor Pluggable Module SFP+* SFF-8431
[^fibrechannel]: *FC-PH Fibre Channel Physical Interface* INCITS 230-1994
[^ethernet]: *Ethernet Specification* IEEE-802.3
@@ -38,3 +127,9 @@ RGMII, SGMII, 1000BaseX standards allow a speed of 1 Gbps, 2.5BaseX and HSGMII s
[^10gbasecx4]: *Physical Coding Sublayer (PCS) and Physical Medium Attachment (PMA) sublayer, type 10GBASE-X* https://www.ieee802.org/3/ak/public/jan03/WPcls48_1_0.pdf
[^aquantia]: *AQR405 10GBASE-T Ethernet PHY Transceiver* https://www.verical.com/datasheet/aquantia-corp.-phy-aqr405-b1-eg-y-3825278.pdf
[^xilinx]: *USXGMII Ethernet Subsystem v1.2* https://www.xilinx.com/content/dam/xilinx/support/documents/ip_documentation/usxgmii/v1_2/pg251-usxgmii.pdf
+[^sff8024]: *SFF Module Management Reference Code Tables* SFF-8024
+[^linux-phylink]: *SFP and phylink*, The Linux Kernel documentation https://docs.kernel.org/networking/sfp-phylink.html
+[^linux-sfpbus]: `sfp_parse_support()`, Linux kernel https://github.com/torvalds/linux/blob/master/drivers/net/phy/sfp-bus.c
+[^linux-sfp]: SFP quirks, Linux kernel https://github.com/torvalds/linux/blob/master/drivers/net/phy/sfp.c
+[^rtl960x]: *HSGMII/2.5GBase-X speed*, Anime4000/RTL960x https://github.com/Anime4000/RTL960x/issues/17#issuecomment-1151207447
+[^wiki-gbe]: *Gigabit Ethernet - Fiber optics*, Wikipedia https://en.wikipedia.org/wiki/Gigabit_Ethernet#Fiber_optics