Re: [RFC] net: towards a generic PON framework

[Ziyou Xu <xuziyougm@gmail.com>]

Hi Andrew,

I think I skipped over an important layering detail in my previous mail.

An OMCI PDU does have its own protocol header, but on the wire it is 
carried inside the PON transport framing. That lower layer is also where 
the management channel is separated from normal user traffic.

A little terminology may help here.

The OLT (Optical Line Terminal) is the operator-side device, while the 
ONU (Optical Network Unit) is the subscriber-side device.

A PON is point-to-multipoint:

                          OLT
                           |
                     passive splitter
                    /       |       \
                  ONU1     ONU2     ONU3

Downstream traffic from the OLT is physically broadcast through the 
splitter to the ONUs.

Upstream transmission is shared in time. The OLT assigns transmission 
opportunities to individual ONUs, which then transmit optical bursts in 
their granted time slots.

For GPON, the transmission convergence layer is called GTC, and service 
traffic above it is carried using GEM, the GPON Encapsulation Method.

For XG-PON and XGS-PON, the corresponding layer is XGTC and service 
traffic is carried using XGEM.

OMCI is the ONU Management and Control Interface specified by ITU-T G.988.

OMCC is the ONU Management and Control Channel, the logical GEM/XGEM 
connection over which OMCI PDUs are transported.

PLOAM is another management mechanism at the TC/physical layer. It is 
used during activation for things such as ONU identification, ranging 
and assignment of transport resources. PLOAM and OMCI are separate 
protocols.

So, very approximately:

                  service plane        management plane

                   service SDU              OMCI
                        |                     |
                        |                  G.988 PDU
                        |                     |
                        +----------+----------+
                                   |
                               GEM / XGEM
                                   |
                               GTC / XGTC
                                   |
                               PON optical PHY

For GPON, a GEM frame starts with a five-octet header.

ITU-T G.984.3 defines it roughly as:

      bit
        0          11 12         23 24  26 27          39
        +-------------+-------------+------+--------------+
        |   PLI (12)  | Port-ID (12)| PTI  |   HEC (13)   |
        +-------------+-------------+------+--------------+
        |<---------------- 5 octets --------------------->|

        PLI       Payload Length Indicator
        Port-ID   GEM logical connection identifier
        PTI       Payload Type Indicator
        HEC       Header Error Control

and the frame is:

        +-----------------------+--------------------------+
        | GEM header, 5 octets  |       GEM payload       |
        +-----------------------+--------------------------+

The field relevant here is the Port-ID.

A GEM Port-ID identifies a logical connection; it is not an Ethernet 
port number. Normal service traffic is transported on service GEM 
Port-IDs, while the OMCC is transported on a GEM Port-ID assigned for 
management.

During GPON activation, the OLT configures the GEM Port-ID used by the 
OMCC through PLOAM.

A receive path can therefore look roughly like:

                     downstream GTC
                          |
                          v
                     +-----------+
                     | GEM engine|
                     +-----+-----+
                           |
                       Port-ID demux
                           |
                +----------+----------+
                |                     |
         service Port-ID         OMCC Port-ID
                |                     |
                v                     v
        service datapath          OMCI adapter
                                      |
                                      v
                                   OMCI PDU

XG-PON/XGS-PON use the same general idea with XGEM.

An XGEM header is eight octets:

      bit
        0       13 14 15 16        31 32        49 50 51        63
        +----------+-----+------------+------------+--+------------+
        | PLI (14) | Key | Port-ID(16)| Options(18)|LF|  HEC (13)  |
        +----------+-----+------------+------------+--+------------+
        |<--------------------- 8 octets -------------------------->|

Again, the Port-ID identifies the logical XGEM connection.

For XG-PON/XGS-PON, the OMCC is associated with a dedicated XGEM 
Port-ID, and the PON MAC/OMCI adapter can select and de-encapsulate 
those frames before passing the OMCI PDU further up.

So, regarding:

 > How can you tell apart a OMCI PDU from a user data PDU?

That distinction is normally made using the GEM/XGEM Port-ID before the 
OMCI implementation sees the packet.

Conceptually:

              optical stream
                   |
                GTC/XGTC
                   |
               GEM/XGEM
                   |
              Port-ID demux
                   |
              OMCC selected
                   |
         GEM/XGEM header removed
                   |
                   v
              raw OMCI PDU

The OMCI PDU itself also has its own protocol header.

For example, the beginning of a baseline OMCI message contains:

      bit
        0                    15 16       23 24       31
        +----------------------+-----------+-----------+
        | Transaction ID       | Msg type  | Device ID |
        +----------------------+-----------+-----------+
       32                    47 48                    63
        +----------------------+-----------------------+
        | ME class             | ME instance           |
        +----------------------+-----------------------+
        |                                              |
        |              message contents                |
        |                      ...                     |

The transaction identifier associates a command with its response. The 
message type identifies an OMCI operation such as Create, Delete, Set or 
Get.

The ME class and ME instance identify the Managed Entity being operated 
on. These can represent things such as the ONU itself, a T-CONT, GEM 
port, Ethernet UNI, VLAN configuration object, etc.

So when I referred to a "raw OMCI PDU", I meant something like:

         +-------------+----------------+-----+
         | OMCI header | OMCI contents  | MIC |
         +-------------+----------------+-----+

rather than:

         +-----------------+-------------+-----+
         | GEM/XGEM header | OMCI PDU    | ... |
         +-----------------+-------------+-----+

The GEM/XGEM framing has already been handled by the PON side before 
that point.

For AF_PACKET, what I had in mind was exposing this 
already-demultiplexed OMCI PDU.

Your point about protocol-specific capture headers is interesting as well.

Depending on the hardware, some information from the PON side may still 
be available after de-encapsulation. A small capture pseudo-header could 
carry things such as direction, the GEM/XGEM Port-ID, PON interface 
information, or a hardware timestamp where available.

That would be capture metadata rather than part of the OMCI PDU itself.

This also makes me wonder whether we need a Generic Netlink interface 
for the OMCI path at this stage.

If the immediate userspace requirement is simply transporting 
already-demultiplexed OMCI PDUs, AF_PACKET already provides a packet 
transport abstraction.

Without a packet endpoint, we would need to define equivalent RX/TX and 
packet-delivery semantics through another interface such as Generic 
Netlink. I am not yet sure what we would gain from doing that if the 
object crossing the boundary is simply an opaque OMCI PDU.

Other PON state could remain internal to the kernel or use existing 
subsystems until there is a concrete operation which needs an 
xPON-specific control UAPI.

So the part I am still trying to understand is whether a minimal 
non-Ethernet net_device, used only as an AF_PACKET endpoint for these 
already-decapsulated OMCI PDUs, would itself be considered the wrong 
abstraction.

If so, the hostapd/nl80211 model may indeed be a better fit, but I think 
it would be useful to understand what property of that model is 
preferable for this particular packet stream.

References:

ITU-T G.984.3
Gigabit-capable passive optical networks (G-PON):
Transmission convergence layer specification
https://www.itu.int/rec/T-REC-G.984.3

ITU-T 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

ITU-T G.9807.1
10-Gigabit-capable symmetric passive optical network (XGS-PON)
https://www.itu.int/rec/T-REC-G.9807.1

ITU-T G.988
ONU management and control interface (OMCI) specification
https://www.itu.int/rec/T-REC-G.988

Thanks,
Ziyou