Date:   Mon, 7 Nov 2022 09:43:12 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <aahringo@...hat.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 Alexander,

aahringo@...hat.com wrote on Sun, 6 Nov 2022 20:30:48 -0500:

> 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.

Great!

> The
> future will show if there are any "special" requirements and how we
> could react here.

Agreed.

> > > 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.

Ok, I'll do!

Thanks,
Miquèl

Powered by blists - more mailing lists