Hi ,
Thanks for your response.
The switch / change interface among the STA or MLO Link shall happen
only in the disconnected state.
At this point, (in the disconnected state) these MLO Link wdev’s are
not
linked to the STA interface ( either on the same / different wiphy
).
These shall be linked after the Association to an MLO AP.
The intention here is to have the wdev in the right mode ( STA or
MLO
Link ) before the connect / Association is triggered.
This wdev is put in to a MLO_LINK_DEVICE, before the connect /
association is triggered on the respective MLD (IFTYPE_STA)
interface
for an MLO connection.
This wdev is put in the IFTYPE_STA mode, before triggering a connect
/
association on this interface.
This should be applicable for different drivers too.
Please let us know if there are any caveats in this design
Just to summarize, to see if I'm understanding it correctly.
You're basically saying that on the client side
1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with
whatever
MAC address it may have, and does not maintain its "own"
association
to an AP;
2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the
DEVICE
it's long enough) are added to it, with appropriate link
addresses
selected for them;
3) this configuration can only happen while none of them are
connected.
Right?
No . Our intention was the NL80211_IFTYPE_STATION interface to also
represent
the MLD + MLO Link while the NL80211_IFTYPE_MLO_LINK wdevs represents
other MLO
Links of an MLO connection.
This MLO_LINK wdev will not have its netdev. The IFTYPE_STATION wdev
shall
link all such MLO_LINK’s which are part of the same MLD connection.
That way , there will be a single netdev interface exposed to the
applications
for the data transfer and these MLO_LINK wdevs along with
NL80211_IFTYPE_STATION
wdev represent the corresponding connection/link status with the MLD
AP.
Please note that in this case the NL80211_IFTYPE_STATION Acts as both
the MLD
and one of the MLO Link’s.
Wrt. MAC addresses, I suppose from our pure software POV the
_MLO_LINK
could share a MAC address with the MLD (_STATION), although I hear
that
there's still a discussion right now on MLD-addressed and
link-addressed
management frames, so I think we need to wait until we know that for
sure.
A couple of questions:
1) How do we present this to userspace, is that it? Wouldn't the
_STATION (MLD) interface ideally still have *some* visible
wireless
state, and show which network it's connected to? It might be very
awkward to require all userspace tools to be updated to know
about
and query for _MLO_LINKs.
Obviously, wpa_supplicant needs to be aware of these and can
handle
it just fine, so I'm more concerned about other userspace. After
all, people still use tools built on wireless extensions
As I have mentioned above , the _STATION is both the MLD and one of
the
MLO Links.
This shall still have the connected state with its MLO Link
representing
the connection info with the AP.
The other MLO Link of a 2 Link MLO connection to the AP (for example)
is
represented by the _MLO_LINK wdev.
Userspace tools can still see this _STATION as both the MLD and non
MLD
station interface connection.
For an MLD connection this _STATION interface will also link with the
corresponding _MLO_LINK wdev’s and thus any
MLO aware user applications can as well get the connection stats of
the
corresponding MLO Links along with _STATION link through the _STATION
interface.
2) In some ways related to 1), but in other ways also not - perhaps
we
need to anticipate that some devices will want to handle MLO link
decisions in firmware? I haven't thought about this much at all,
but
if we require separate MLO_LINK type wdevs for each link that
might
be tricky?
Are you saying that these devices want to totally handle the MLO link
establishments with in the firmware ?
Let me take an example here. I have taken a 2 link MLO for a
reference.
Such devices want to still represent the station interface with
NL80211_IFTYPE_STATION to the cfg80211 and create multiple links with
in
the firmware ?
Technically, the _STATION interface here is connected to 2 BSSID’s .
Can I know What would _STATION(wdev)->current_bss represent here ?
3) I keep thinking about moving much "associated" state into the STA
struct we maintain in the kernel, and actually maintaining the
*links* only as "multiple associations". This also gets tricky
with
the link MAC addresses in a way, though that could be handled. It
might also be an easier way to manage some of that state problem
from my question 1)?
Any thoughts on this? I'm definitely not saying this would be
easy,
but would it simplify things regarding the userspace APIs and the
offload question in 2)?
Can I know how these “multiple associations” would be represented as
to
the user space ?
With your proposal above, the userspace applications shall still see a
single NL80211_IFTYPE_STATION and multiple links are maintained within
this
wdev ?
Fine , this would work as long as these links are with in the same
wiphy.
Let me present the two use cases we considered MLO for.
1)single wiphy to represent multiple bands on which the MLO Links can
be formed :
In this case the _STATION interface would be on a single wiphy and
yeah your
proposal would hold good. We initially thought on similar lines.
Thanks.
2) single wiphy for each supported band: Say there are two wiphy’s
here , each
representing the respective bands 2G and 5G/6G. In this specific case,
the non
MLO solution had two _STATION interfaces connecting to the AP’s on
respective bands.
We are aiming to enhance this design for MLO . In this case, the MLO
Links spawn
across different wiphy’s and at the same time has to be backward
compatible for
the non MLO connection ( dual STA ) .
To suite the above two use cases , we proposed the introduction of
_MLO_LINK wdev
and the _STATION interface to link all the _MLO_LINK wdev’s that are
part of the
respective MLD connection.
Thus, a _STATION wdev can be changed to the _MLO_LINK wdev and vice
versa to have
both the MLO and non MLO connection (Dual STA).
Any other designs than the MLO_LINK wdev that you have considered
and discarded, and if so for which reasons?
The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO
Link”
on the non-AP MLD.This would not be required for an AP MLO.
FWIW, I don't buy the part about this not being required for an AP
MLD.
The following explains our design for AP.
For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance
for
non-MLO / legacy client and an MLO link for AP-MLD.
To be specific, For a 2 link AP MLD , there will be 2
NL80211_IFTYPE_AP
wdev's created.
This will not work if there's a need (and possibly spec requirement)
to
have an MLD address that's different from *all* the link addresses.
It
will also be difficult to manage that one of the AP interfaces would
have to be defacto the MLD, but (at least in theory) any one of the
AP
interfaces could be removed for 'degraded' operation.
I suspect will also not work right if you want to have AP_VLAN on the
AP
MLD.
IMHO it'd be better for things to be symmetric like you suggest for
the
client side.
Now, I can see the need for legacy interoperability, but then it
seems
it would probably be better to do this the other way around and
declare
a new AP_MLD interface type (with a netdev) that doesn't maintain its
own beacons etc. but just has its own MAC address (the AP MLD
address)
and bubbles up the data frames exchanged on the MLD.
OK. A new AP_MLD with a netdev to represent the MLD. I guess this is
to
only facilitate the need for a different MLD address over the MLO link
addresses?
Taking an example , A 2 MLO AP would have the following . Please
correct me .
Two _ IFTYPE_AP wdev’s , representing a Link for an MLD AP and an AP
instance
for a non MLD AP ( for the legacy clients to connect ). These two
wdev’s maintain
their own beacon’s and do have the corresponding netdev’s.
A new AP_MLD with it’s own netdev but doesn’t maintain it’s beacon.
The two
_IFTYPE_AP wdev’s, representing the link shall point to this AP_MLD
interface
for the MLD address ?
We had seen some concerns on this model and please allow me to get
back to you
as early as possible.
