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

[Gaoyang Wei <yhyxwgy@gmail.com>]

Hi Andrew,

 > Another question which might affect the architecture. From what you
 > have described, an ONU might be assigned multiple Port-IDs so it can
 > carry multiple, separated, service traffic streams? You would want to
 > represent each stream as a Linux netdev, with its own IP addresses
 > etc.

An ONU can indeed have multiple GEM Port-IDs, but I think there is one
important distinction here: a GEM Port-ID is not necessarily equivalent
to one Linux service interface.

G.988 has an interworking layer between the GEM connections and the
Ethernet-facing service.

For example, one Ethernet UNI can use an IEEE 802.1p mapper which sends
different priority classes to different GEM ports.  Bridge and VLAN
configuration can also make the relationship between Ethernet services
and GEM connections non-1:1.

Very roughly:

                       Ethernet UNI
                            |
                    bridge / mapper /
                      VLAN handling
                      /     |     \
                     /      |      \
               GEM port  GEM port  GEM port
                  100       101       102

So I think GEM Port-IDs are better viewed as PON bearer resources.

A Linux netdev should represent an actual service interface where that
is meaningful, rather than automatically creating one netdev for every
GEM Port-ID.

This is also why I was hesitant in the original RFC to make GEM ports
the central Linux object.  They are important hardware resources, but
the Linux service topology above them can be different.

 > This again made me think of 802.11 in Linux. I'm not too familiar with
 > it, but it has the concept of a wiphy, which represents the lowest
 > levels of the hardware. You can then instantiate clients & access
 > points on top of it, each being a linux netdev.
 >
 > [...]
 >
 > You might need something similar, an entity which represents the lower
 > levels of the ONU, and then you instantiate netdevs on top of it as
 > dictated by management.

I think this may be the missing abstraction.

It also fits very well with your AF_OMCI suggestion in the other mail.

When I originally thought about a packet-oriented OMCI interface,
SocketCAN was one of the models I had in mind: a non-Ethernet protocol
using the Linux networking stack and normal socket/packet tooling.

But your AF_OMCI suggestion makes me think I may have borrowed the
wrong part of that model.

With SocketCAN, can0 represents a real CAN interface, and PF_CAN
sockets operate on that interface:

         physical CAN controller
                  |
                can0
                  |
           PF_CAN socket binds
              to can0

The CAN protocol itself does not require creating another synthetic
interface next to can0.

Ziyou's current OMCI implementation effectively looks more like:

                   PON hardware
                   /          \
            Ethernet path     omci0
                                 |
                             AF_PACKET

where omci0 exists mainly to provide a packet endpoint for the
already-demultiplexed OMCI PDUs.

Putting your two suggestions together seems to lead to a cleaner model:

                      +------------------+
                      |    PON device    |
                      |  (wiphy-like)    |
                      +--------+---------+
                               |
                 +-------------+-------------+
                 |                           |
              AF_OMCI                 service interfaces
                 |                           |
           OMCI userspace             Linux net_device(s)
                                             |
                                    VLAN / TC / bridge
                                             |
                                       GEM mapping

The PON object would represent the common lower level: the PON MAC,
line/activation state, and its relationship with the optical frontend.

The service netdevs above it would represent actual Linux-visible
Ethernet services where needed.

The GEM/T-CONT resources would remain below that service abstraction.
They could still be managed or offloaded by the driver, but there
would not necessarily be one netdev per GEM Port-ID.

This also gives a much stronger reason for one of the original RFC
questions about whether Linux needs a struct pon_device or equivalent.

Initially I was thinking such an object might mainly be useful as a
container for PON-specific state and resources such as GEM ports and
T-CONTs.

A wiphy-like model suggests a simpler and more fundamental purpose:
represent the shared PON line/hardware itself.

The minimum object might therefore only need to represent things such
as:

         PON mode
         activation / line state
         associated PON MAC / driver
         associated optical frontend
         service-interface relationships
         management-protocol attachment points

without making the complete GEM/T-CONT/service graph part of the first
generic API.

That also seems to answer part of the question raised by your AF_OMCI
idea.

If OMCI is a protocol associated with this lower-level PON object,
then there is no need for a synthetic omci0 merely to obtain
AF_PACKET semantics.

Conceptually the receive path becomes:

              PON MAC
                 |
          GEM/XGEM demux
           /           \
    service bearer      OMCC
         |               |
  service mapping     OMCI PDU
         |               |
      netdev(s)        AF_OMCI

and TX follows the reverse path.

I would still avoid defining the AF_OMCI socket ABI at this point,
because one question remains: unlike can0, a wiphy itself is not a
net_device.

So if the PON parent is similarly a non-netdev object, AF_OMCI would
need some way to identify the PON object rather than simply binding to
a service-netdev ifindex.

I do not think that is a reason to create another synthetic net_device
just to obtain an ifindex, though.  It seems better to first decide
what represents the PON device, and then design the management
protocol attachment around that object.

Is that approximately what you had in mind with the wiphy analogy?

I think packet capture should be kept separate from this question as
well.  Good observability of OMCI traffic is still important for PON
interoperability debugging, but that does not require the OMCI
transport endpoint itself to be a net_device.

Thanks,
Gaoyang