Message-ID: <CAK-6q+j4pCQNj5paCAXMNvtHi9+DHxW8wZH2-ZpbxKgpbe8R0Q@mail.gmail.com>
Date:   Sun, 6 Nov 2022 20:30:48 -0500
From:   Alexander Aring <aahringo@...hat.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Guilhem Imberton <guilhem.imberton@...vo.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

Hi,

On Fri, Nov 4, 2022 at 2:17 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@...hat.com wrote on Thu, 3 Nov 2022 20:55:38 -0400:
>
> > Hi,
> >
> > On Wed, Nov 2, 2022 at 10:52 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > >
> > > Hi Alexander,
> > >
> > > aahringo@...hat.com wrote on Sun, 30 Oct 2022 22:20:03 -0400:
> > >
> > > > Hi,
> > > >
> > > > On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > > > >
> > > > > Hello,
> > > > > These three patches allow the creation of coordinator interfaces, which
> > > > > were already defined without being usable. The idea behind is to use
> > > > > them advertizing PANs through the beaconing feature.
> > > > >
> > > >
> > > > I still don't know how exactly those "leaves" and "non-leaves" are
> > > > acting here regarding the coordinator interfaces. If this is just a
> > > > bit here to set in the interface I am fine with it. But yea,
> > > > "relaying" feature is a project on its own, as we said previously.
> > > >
> > > > Another mail I was asking myself what a node interface is then,
> > > > currently it is a mesh interface with none of those 802.15.4 PAN
> > > > management functionality?
> > >
> > > Not "none", because I would expect a NODE to be able to perform minimal
> > > management operations, such as:
> > > - scanning
> > > - requesting an association
> > > But in no case it is supposed to:
> > > - send beacons
> > > - manage associations
> > > - be the PAN coordinator
> > > - act as a relay
> > >
> >
> > perfect, thanks. But still there is something which I don't get.
> >
> > The split you mentioned about the functionality is for me being a
> > coordinator (IEEE spec) or pan coordinator (IEEE spec) which has the
> > additional functionality of "send beacons, manage assocs, act as
> > relay".
>
> I would expect any coordinator (IEEE spec) to be able to send beacons
> and relay (but in this case it only makes sense to send beacons if
> relaying is supported, IMHO).
>
> The PAN coordinator (IEEE spec) only has the following additional
> capability: managing assocs within the PAN. But in practice it is very
> likely that it is the one with the greater computational resources and
> the highest networking capabilities (it is usually the one which acts
> as a bridge with eg. the internet, says the spec).
>
> > So a coordinator (iftype) is a pan coordinator (IEEE spec) and a node
> > (iftype) is a coordinator (IEEE spec), but _only_ when it's
> > associated, before it is just a manually setup mesh node?
>
> Mmmh, actually this is not how I see it. My current mental model:
> - COORD (iftype) may act as:
>   * a leaf device (associating with the PAN coordinator, sending data)
>   * a coordinator (like above + beaconing and relaying) once associated
>   * a PAN coordinator (like above + assoc management) if the device
>     started the PAN or after a PAN coordinator handover.
>   Note: physically, it can only be authorized on FFD.
> - NODE (iftype) may only be a leaf device no matter its association
>   status, this is typically a sensor that sends data.
>   Note: can be authorized on any type of device (FFD or RFD).
>
> If I understand correctly, your idea was to change the interface type
> depending of the role of the device within the network. But IMHO the
> interface type should only be picked up once for all in the lifetime of
> the device. Of course we can switch from one to another by quickly
> turning off and on again the device, but this is not a common use case.
> We must keep in mind that PAN coordinator handover may happen, which
> means the interface must stay on but stop acting as the PAN
> coordinator. Using two different interface types for that is not
> impossible, but does not seem relevant to me.
>
> Would you agree?
>

Okay, I think that if you have a node then you never want to act as
any PAN coordinators functionality. And yes it seems complicated to
switch such functionality during runtime. I am fine with that. The
future will show if there are any "special" requirements and how we
could react here.

> > I hope it's clear when meaning iftype and when meaning IEEE spec, but
> > for the manual setup thing (node iftype) there is no IEEE spec,
> > although it is legal to do it in my opinion.
>
> It's clear, no problem. In my previous e-mails, when talking about the
> interfaces I used the uppercase NODE and COORD keywords, while I used
> the plain english lowercase "[leaf] node", "coordinator" or "PAN
> coordinator" words when talking about the IEEE definitions.
>

That is great, we should use those terms to make the difference.

Thanks.

- Alex

Powered by blists - more mailing lists