12 files changed, 145 insertions, 1 deletions

diff --git a/_config.yml b/_config.yml
index b4a609d..abb37b0 100644
--- a/_config.yml
+++ b/_config.yml
@@ -105,6 +105,9 @@ collections:
   tools:
     permalink: "/:path/"
     output: true
+  sfp:
+    permalink: "/:path/"
+    output: true
   gpon:
     permalink: "/:path/"
     output: true
@@ -123,8 +126,11 @@ just_the_docs:
     tools:
       name: Tools
       nav_fold: true
+    sfp:
+      name: SFP Resources & standard
+      nav_fold: true
     gpon:
-      name: GPON Resources
+      name: GPON Resources & standard
       nav_fold: true
     sfp_cage:
       name: SFP cage
diff --git a/_sfp/bosa-tosa-rosa.md b/_sfp/bosa-tosa-rosa.md
new file mode 100644
index 0000000..a893170
--- /dev/null
+++ b/_sfp/bosa-tosa-rosa.md
@@ -0,0 +1,23 @@
+---
+title: "BOSA, TOSA and ROSA: the conversion from optical to electrical"
+has_children: false
+nav_order: 3
+layout: default
+---
+
+In optical-electrical conversion, special components called TOSA (Transmitter Optical Sub Assembly) and ROSA (Receiver Optical Sub Assembly) are used to convert the signal.
+They are responsible for translating the optical signal into a corresponding electrical signal or vice versa, which inputs or outputs symbols corresponding to the optical values. These values, which we refer to as unprocessed or RAW values for simplicity, are not standard signals and must be converted into standard signals[^huawei].
+
+TOSA and ROSA are essential components in the uni-directional transceivers which transmit on one fiber optic strand and receive on the other fiber optic strand. 
+
+{% include image.html file="ont-wo-mac/rosa.png" alt="ROSA" caption="ROSA" %}
+{% include image.html file="ont-wo-mac/tosa.png" alt="TOSA" caption="TOSA" %}
+
+In order to ensure bi-directional communication, it is also possible to use a TOSA and a ROSA, or a BOSA which is a combination of a TOSA, a ROSA and additionally a WDM filter. The WDM filter split the wavelengths into two separate wavelengths[^huawei].
+
+{% include image.html file="ont-wo-mac/bidi.jpg" alt="Bi-Directional comunication obtain through a TOSA and a ROSA" caption="Bi-Directional comunication obtain through a TOSA and a ROSA" %}
+{% include image.html file="ont-wo-mac/bosa.jpg" alt="BOSA" caption="BOSA" %}
+
+---
+
+[^huawei]: *What is inside a SFP transceiver?* https://forum.huawei.com/enterprise/en/what-is-inside-a-sfp-transceiver/thread/782827-861
\ No newline at end of file
diff --git a/_sfp/ont-wo-mac.md b/_sfp/ont-wo-mac.md
new file mode 100644
index 0000000..1d89c2d
--- /dev/null
+++ b/_sfp/ont-wo-mac.md
@@ -0,0 +1,84 @@
+---
+title: SFP with PON MAC and w/o PON MAC
+has_children: false
+nav_order: 2
+layout: default
+---
+
+PON technologies unlike Ethernet are not P2P but one-to-many with two device types: ONU (Optical Network Unit)/ONT (Optical Network Terminal) and OLT (Optical Line Terminal). Both devices can be manufactured using the SFP form factor[^tibit].
+
+The OLT provides an integrated access box for Passive Optical Networks. OLTs are typically chassis with one or more line cards inside, and on each line card there is one or more PON transceiver, usually in SFP form factor. Each line card is connected to a secondary switch that provides line card aggregation to the Ethernet uplinks. OLTs are often a mixture of Layer 2 and Layer 3 switching with traffic shaping on a per-customer, per-service basis[^tibit].
+
+The communication within the SFP PON transceiver is neither MMI nor Ethernet, outside [SFP standards](/sfp-standard.md), but rather it is an *equivalent electrical symbols of optical transmission* (which is simply the input/output of the [BOSA](/bosa-tosa-rosa.md)) that for simplicity's sake we call **PON RAW communication** (also referred to as SFP w/o PON MAC). All the PON management part is left to the line card itself. Each equivalent electrical symbol of optical transmission is a separate dialect, distinct from other dialects. Furthermore, as one can easily guess, this communication is not standard and is not within the signalling standards ([^sfprate],[^sfprate2],[^sfpplusstandard]) but it is compliant with some portions of  the MSA [^sfpstandard],[^sfpplusstandard],[^sfpplusmi]. This requires extreme compatibility between ONT and transreciver. This design choice is made for several reasons:
+- *size*: the size of an OLT w/o PON MAC is very similar to that of an MMI or Ethernet transceiver, and the size of an OLT with the integrated PON MAC far exceeds that of the standard SFP form factor
+- *dissipative heating capacity*: the dissipative heating capacity of an OLT with PON MAC is higher than a normal transceiver, such as a 1 or 10 Gbps Ethernet link.
+- *duplication*: there is a double `MAC` → `MMI` conversion (`MMI` → `MAC` → `PHY` → `MAC` → `OLT CPU`)
+- *repairability*: since lasers often have a shorter lifetime than other ICs, it is good to be able to change only the transceiver
+
+Despite this, there is a vendor that sells OLT SFP with PON MAC[^tibit]. The following pictures show an OLT SFP with PON MAC part and a transreciver without PON MAC. It is interesting to see that the latter is much longer and requires an additional heatsink.
+
+{% include image.html file="ont-wo-mac/tibit.png" alt="PON OLT with MAC" caption="PON OLT with MAC" %}
+{% include image.html file="ont-wo-mac/huawei.png" alt="PON transceiver for OLT w/o MAC" caption="PON transceiver for OLT w/o MAC" %}
+
+Similarly, the same argument can be made for OLT SFPs, especially in 10E-PON and XGS-PON there are a lot of transreceivers w/o PON MAC and few ONTs with PON MAC. In this case the reasons are similar to the previous ones. It is also clear that ONTs w/o PON MAC require a PON MAC part within the end device that supports the relevant communication protocol.
+
+The following pictures show some operating diagrams of some ONT with PON MAC and ONT w/o PON MAC[^SFPP-XGS-ONU-MAC-ASC-I-C],[^SFPP-XGS-ONU-N1-I-C],[^MSOG22-xD6C-xxT1].
+
+{% include image.html file="ont-wo-mac/onu-with-mac.jpg" alt="Physical scheme of an ONT with MAC PON" caption="Physical scheme of an ONT with MAC PON" %}
+
+```mermaid
+graph TD
+    F[fiber] --> A;
+
+    subgraph SFP[SFP with MAC]
+        B -->|Rx| A
+        A[BOSA] -->|Tx| B(BOSA/LD Driver - Limiting Amplifier)
+        
+        B <--> C[PON MAC]
+        C --> N[Nand Flash]
+        C --> E[MCU - EEPROM]
+    end;
+    subgraph CS[Cage SFP]
+    E --> |I2C| Controller;
+    C --> |MMI on Tx - Rx| MAC;
+    Controller[Controller I2C] --> Switch;
+    MAC --> Switch;
+    end;
+```
+
+{% include image.html file="ont-wo-mac/onu-wo-mac.jpg" alt="Physical scheme of an ONT w/o MAC PON" caption="Physical scheme of an ONT w/o MAC PON" %}
+
+```mermaid
+graph TD
+    F[fiber] --> A;
+
+    subgraph SFP[SFP w/o MAC]
+        B -->|Rx| A
+        A[BOSA] -->|Tx| B(BOSA/LD Driver - Limiting Amplifier)
+        B <--> E[MCU - EEPROM]
+    end;
+    subgraph CS[Cage SFP]
+    E --> |I2C| Controller;
+    B --> |RAW PON on Tx - Rx| MAC[PON MAC];
+    Controller[Controller I2C] --> Switch;
+    MAC --> Switch;
+    end;
+```
+
+# Why are there no ONT w/o MAC on Hack GPON?
+
+For utility reasons all SFPs w/o PON MAC are not illustrated on Hack GPON as they are not modifiable like ONT with MAC (they require two inter-compatible devices). 
+
+In particular, the SFP ONU of the AVM Fritz!Box 5530/5590 belongs in this category, and that the above-mentioned devices are not compatible with any other SFP using MMI/Ethernet/Fibre Channel, while for example the FreeBox or IliadBox supports both ONU w/o PON MAC and some SFP with MAC.
+
+---
+
+[^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
+[^sfpplusstandard]: *Enhanced Small Form Factor Pluggable Module SFP+* SFF-8431
+[^tibit]: *ONT Tibit MicroPlug Modules: Architecture* https://tibitcom.com/architecture/
+[^SFPP-XGS-ONU-MAC-ASC-I-C]: *ProLabs SFPP-XGS-ONU-MAC-ASC-I-C* https://s3-us-west-2.amazonaws.com/configurator.computer/55/files/99138/218/SFPP-XGS-ONU-MAC-ASC-I-C/SFPP-XGS-ONU-MAC-ASC-I-C_Datasheets_EN.pdf
+[^SFPP-XGS-ONU-N1-I-C]: *ProLabs SFPP-XGS-ONU-N1-I-C* https://www.prolabs.com/product/SFPP-XGS-ONU-N1-I-C
+[^MSOG22-xD6C-xxT1]: *Mentech MSOG22-xD6C-xxT1* https://www.mnc-optical.com/upload/goods/20201109/202011090724113094.pdf
diff --git a/_sfp/sfp-standard.md b/_sfp/sfp-standard.md
new file mode 100644
index 0000000..66efc48
--- /dev/null
+++ b/_sfp/sfp-standard.md
@@ -0,0 +1,31 @@
+---
+title: SFP standard and ONT
+has_children: false
+nav_order: 1
+layout: default
+---
+
+
+The organisation that developed SFPs (MSA SFP) has always been very cautious about defining a hardened list of admissible signals for SFPs, their first standard only providing pinout, form-factor and dissipative capacity specifications. It is up to the manufacturer to decide which communication to use in the Tx and Rx pins[^sfpstandard]. 
+After the SFP standard entered the market, in the early 2000s Ethernet and Fibre Channel, the MSA SFP also started to standardise 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], 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 BaseX and MMI. The media-independent interface (MMI) was defined in the IEEE 802.11u standard, 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 the MMI 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 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], HSGMII, QSGMII[^qsgmii], XGMII, XSGMII, is widely used as a communication bus over SFP, and is the current standard replacing IEEE BaseX[^ethernet].
+
+RGMII, SGMII, GBaseX standards allow a speed of 1 Gbps, 2.5BaseX and HSGMII standards of 2.5 Gbps, the XGMII, XSGMII and 10GBaseT of 10 Gbps.
+
+
+---
+
+[^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
+[^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
+[^rgmii]: *Reduced Gigabit Media Independent Interface (RGMII) standard* https://web.archive.org/web/20160303212629/http://www.hp.com/rnd/pdfs/RGMIIv1_3.pdf
+[^qsgmii]: *QSGMII Specification* https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/powerquicc/3546/1/qsgmii%20specification.pdf
+[^sgmii]: *CISCO ENG-46158 Serial-GMII Specification* https://archive.org/details/sgmii/page/n5/mode/2up
\ No newline at end of file
diff --git a/assets/img/ont-wo-mac/bidi.jpg b/assets/img/ont-wo-mac/bidi.jpg
new file mode 100644
index 0000000..f25c0c9
--- /dev/null
+++ b/assets/img/ont-wo-mac/bidi.jpg
diff --git a/assets/img/ont-wo-mac/bosa.jpg b/assets/img/ont-wo-mac/bosa.jpg
new file mode 100644
index 0000000..14ed2b4
--- /dev/null
+++ b/assets/img/ont-wo-mac/bosa.jpg
diff --git a/assets/img/ont-wo-mac/huawei.png b/assets/img/ont-wo-mac/huawei.png
new file mode 100644
index 0000000..a214239
--- /dev/null
+++ b/assets/img/ont-wo-mac/huawei.png
diff --git a/assets/img/ont-wo-mac/onu-with-mac.jpg b/assets/img/ont-wo-mac/onu-with-mac.jpg
new file mode 100644
index 0000000..bb7428a
--- /dev/null
+++ b/assets/img/ont-wo-mac/onu-with-mac.jpg
diff --git a/assets/img/ont-wo-mac/onu-wo-mac.jpg b/assets/img/ont-wo-mac/onu-wo-mac.jpg
new file mode 100644
index 0000000..bc991c7
--- /dev/null
+++ b/assets/img/ont-wo-mac/onu-wo-mac.jpg
diff --git a/assets/img/ont-wo-mac/rosa.png b/assets/img/ont-wo-mac/rosa.png
new file mode 100644
index 0000000..35df675
--- /dev/null
+++ b/assets/img/ont-wo-mac/rosa.png
diff --git a/assets/img/ont-wo-mac/tibit.png b/assets/img/ont-wo-mac/tibit.png
new file mode 100644
index 0000000..03f5c71
--- /dev/null
+++ b/assets/img/ont-wo-mac/tibit.png
diff --git a/assets/img/ont-wo-mac/tosa.png b/assets/img/ont-wo-mac/tosa.png
new file mode 100644
index 0000000..ae56957
--- /dev/null
+++ b/assets/img/ont-wo-mac/tosa.png